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FOREWORD 


The  TTCP  Technical  Panel  on  Software  En^neering  (XTP-2)  is  grateful  to  the  U.S.  Amw 
Cbmnninicatkais-ElectiDnics  Corcaiand  (CECX)\Q,  espedalfy  the  Center  for  Software  Engineering, 
for  prodding  the  resources  and  dedicated  efibrts  which  made  this  Workshop  possible.  It  was  quite 
evident  from  the  excitement  of  the  participants,  the  dynamics  that  occurred,  and  the  smoothness 
which  the  sessions  proceeded  that  exienshe  planning  and  preparation  went  into  the  efforts  of  hosting 
the  Workshop.  In  addition,  the  Panel  extends  its  gratitude  to  the  General  Chairperson,  the 
Workshop  Coordinator.  Working  Group  Chairpersons,  and  all  the  participants  who  worked  long  and 
late  to  make  the  outcome  successful  in  every  w^.  We  are  hopeful  that  the  effort  was  as  benencial 
for  all  the  participants  as  it  w-as  for  the  Panel  Members. 

Fulfillment  of  the  Workshop  objectives  (to  survey,  evaluate  and  promote  the  use  of  requirements 
engineering  and  rapid  proto^ping  for  improving  the  quali^  of  requirements  for  mission'Critical 
defense  systems)  led  to  development  of  issues  and  recommendations,  for  the  member  TTCP 
Governments,  in  both  management  and  technical  areas.  These  are  under  review'  and  in  some  areas 
appropriate  actions  are  already  underway. 

Recognizing  the  importance  and  the  potential  of  achieving  major  improvements  in  requirements 
engineering  and  rapid  proto^ing,  the  participants  strongly  suggested  a  follow-up  workshop  within 
the  next  few  years.  The  TTCP  Panel  will  closely  monitor  future  developments  in  this  area,  and  will 
fully  consider  this  suggestiotL 


/’’^^jDseph  C.  Batz 

Chairman,  TTCP  XTP-2 
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EXECUTIVE  SUMMARY 


1.1  Introduction 

For  both  commercial  and  militaiy  computer-based  ^-stems,  it  is  rare  that  the  true  needs  of 
all  stakeholders  are  fully  stated  and  understood  from  the  outset,  nor  are  the  requirements  that 
are  understood  always  agreed  upon  by  all  parties.  In  addition,  requirements  that  have  been 
documented  are  sometimes  subject  to  interpretation  by  both  users  and  developers.  Even 
when  requirements  have  been  baselined,  developers  have  difficulty  in  anticipating,  controlling, 
and  mana^g  changes  to  the  baseline. 

These  problems  are  a  result  of  the  lack  of  a  well-defined  Requirements  Engineering  (RE) 
discipline  which,  in  turn,  results  in  cost  overruns,  schedule  slippages,  poor  quality,  and  systems 
that  fail  to  satisfy  mission  needs. 

The  US  Army  CECOM  Center  for  Software  Engineering  hosted  the  Requirements 
Engineering  and  Rapid  Prototyping  Workshop  in  Eatontown,  NJ  on  November  14-16  1989. 
This  event  was  sponsored  by  The  Technical  Cooperation  Program’s  (TTCP)  Panel  on 
Software  Engineering. 

Many  of  the  workshop’s  forty-nine  participants  are  leading  experts  in  Requirements  and 
Software  Engineering.  They  met  to  share  current  information  on  the  field,  to  identify  and 
clarify  the  most  pressing  issues,  and  to  provide  recommendations  to  Department  of  Defense 
(DoD)  for  management,  development,  and  research  relating  to  Requirements  Engineering. 

These  Proceedings  document  the  presentations  and  findings  of  the  workshop  and  its  three 
working  groups. 


1.2  The  Requirements  Engineering  Process 

Chairperson:  Dr.  Alan  M.  Davis 

The  group  identified  the  following  issues  as  having  the  highest  priority:  coping  with 
requirements  uncertainty  and  change;  validating  requirements;  achieving  consensus  among 
multiple  stakeholders;  and  measuring/tracking  progress  in  requirements  development. 

The  group  members  recommended  the  following  for  management:  use  an  evolutionary 
acquisition  approach;  make  personnel  and  stakeholders  aware  of  acquisition  alternatives  and 
related  technologies  such  as  prototyping;  involve  all  stakeholders  in  requirements 
determination  and  validation;  orient  acquisition  and  incentives  around  requirements 
"progress";  introduce  risk-based  requirements  related  decision  making  (multi-attribute  utility, 
cost-benefit,  Pareto  optimization,  etc.);  and  reduce  barriers  to  developer-user  interaction. 
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For  development,  th^  recommended  that  requirements  be  frozen  in  small  incremental  builds 
and  that  more  testbed  be  developed  to  validate  interoperability  earlier  in  the  requirements 
process. 

Finally,  for  research  th^  recommended  developing  the  following  technologies  and  disciplines: 
requirements  partitioning;changemanagement;formalspecification:multi-stakeholderprocess 
support;  requirements  normalization;  process  models;  measurement  techniques  for 
requirements  progress;  tools  and  techniques  to  capture  merits/trade-offs  among  requirements; 
and  the  selection  of  the  appropriate  acquisition  and  requirements  technique  for  a  given 
project 


1.3  Requirements  Engineering  Methodology,  Tools,  and  Languages 

Chairperson:  Dr.  Raymond  T.  Yeh 

This  group  identified  the  following  polity  and  management  related  issues:  a  lack  of 
management  awareness  of  the  significance  and  importance  of  Requirements  Engineering;  and 
a  lack  of  recognition  that  this  discipline  must  be  supported  throughout  a  system’s  life  cycle. 

For  development  and  research,  they  focussed  on  the  following  issues:  the  capture  of 
requirements  related  information;  non-functional  requirements  (the  "ilities");  tool  and 
technology  integration;  technology  insertion  for  existing  systems;  and  the  measurement  of  key 
requirements  process  parameters. 

The  working  group  recommended  the  following  for  policy  and  management:  adopt  and 
support  a  requirements-centered  development  life  cycle  model;  educate  and  train  personnel 
in  Requirements  Engineering;  establish  a  Requirements  Engineering  information/consultation 
center;  and  reallocate  currently  available  research  funds  to  support  Requirements 
Engineering,  spending  less  resources  on  downstream  software  activities  (i.e.,  concentrate  more 
resources  on  identifying  and  confirming  what  is  to  be  built,  rather  than  on  how  to  build  it). 

For  development  and  research,  they  recommended  developing  the  following:  a  wide  spectrum 
language  which  supports  acquisition,  representation,  and  reuse  of  requirements  information; 
methods  to  capture,  integrate,  and  measure  non-functional  requirements;  an  integrated 
environment  of  Requirements  Engineering  tools;  methods  and  tools  which  support  reverse 
engineering  of  current  system’s  requirements  documentation;  requirements  validation 
techniques;  new  approaches  for  requirements  trade-off  analysis;  and  metrics  which  support 
modem  Requirements  Engineering  practices. 


1.4  Knowledge-Based  Techniques  and  Rapid  Prototyping 

Chairperson:  Dr.  Winston  W.  Royce 

This  group  analyzed  two  specific  aspects  of  Requirements  Engineering:  knowledge-based 
techniques  and  rapid  prototypying. 
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The  group  identified  the  follovnng  issues  which  relate  to  knowledge-based  techniques:  the  use 
of  Knowledge  Based  Approaches  (KBA)  and  their  application  to  real  systems;  the  risks  and 
benefits  of  using  KBA’s  for  Requirements  Engineering;  the  nature  of  a  O  A  specific  software 
development  process  model;  and  the  identification  of  existing  knowledge-based  technology. 

The  following  were  the  group’s  management  and  policy  recommendations:  adopt  policy  and 
models  that  allow  for  incremental,  evolutionary  development  and  which  accommodate  KBA; 
invest  in  knowledge  base  development  early  in  the  acquisition  phase;  and  reuse  knowledge 
bases  in  related  projects,  to  amortize  investments  across  many  projects. 

For  KBA  development,  they  recommended  learning  from  past  KBA  experience  and  trying 
KBA  in  a  large,  real  project 

Research  recommendations  were:  experiment  using  KBA  for  verification  and  validation  (V 
&  V);  research  KBA  knowledge  acquisition  and  management,  especially  in  light  of  existing 
methodologies  and  tools;  and  research  knowledge  base  models  with  advanced  degrees  of 
expressiveness. 

Rapid  prototyping  issues  that  were  identified  were:  participants  and  products  in  the 
prototyping  process;  standards  and  current  practices;  and  uses,  properties,  and  examples  of 
prototyping  systems  and  tools. 

Management,  policy  and  development  recommendations  for  rapid  prototyping  were  as  follows: 
train  personnel  in  the  prototyping  approach;  modify  the  development  stages  and  time  frames 
to  be  supportive  of  prototyping;  define  the  objectives  of  requirements/design  reviews  which 
use  prototyping  products;  support  competitive  prototyping  efforts;  and  consider  acquisition 
models  that  include  prototyping. 

Finally,  recommendations  for  research  programs  were  proposed  for  the  following: 
requirements  traceability;  validation  of  non-functional  requirements;  automatic 
prototype-to-documentation  generation;  stakeholder  communication;  legal  issues;  and  lessons 
learned  from  prior  prototyping  efforts. 


1.5  Recommendations  and  Conclusions 

The  workshop  produced  many  valuable  insights  and  recommendations.  These  insights  and 
recommendations  are  fully  documented  in  these  Proceedings.  It  is  important  to  note  that 
although  the  three  groups  worked  independently,  a  number  of  recommendations  were 
common  to  the  three  groups.  Every  group  saw  the  need  for  the  DoD  to  change  policy  to 
accommodate  evolutionary  acquisition.  The  groups  also  saw  the  need  for  increased  training 
for  Government  acquisition  personnel  to  make  them  more  aware  of  Requirements 
Engineering  issues  and  techniques.  Every  group  saw  the  need  for  additional  emphasis  and 
research  in  requirements  validation.  Most  of  the  participants  recognized  the  need  for 
additional  research  in  defining  and  using  methods  of  measuring  attributes  and  progress  in  the 
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Requirements  En^neering  process.  Most  identified  the  need  for  further  work  in  speci^'ing 
non-functional  requirements.  It  was  recommended  that  tools  and  techniques  be  developed 
which  aid  in  identifying  merits  and  trade-o^  among  requirements.  Additional  research  in 
requirements  traceabiUfy  was  also  suggested.  It  was  also  recommended  that  continued  special 
emphasis  be  given  to  multiple  stakeholder  issues  as  the  Requirements  Engineering  process 
evolves.  Finally,  and  most  obviously,  it  was  concluded  that  it  is  not  enough  to  merely  develop 
technologies.  We  must  apply  them  as  well 
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2  WORKSHOP  CHARGE 


By:  George  E.  Sumrall,  Workshop  Chairperson 


Computer  technology  as  we  know  it  today  is  barely  forty  years  old.  We  have  made 
tremendous  strides,  in  both  hardware  and  software.  Back  in  the  early  days,  computers  were 
the  size  of  a  wall  and  often  Glled  a  room.  Now,  you  can  hold  one  in  your  hand.  With 
products  like  dBase  or  Lotus,  you  can  store,  manage,  and  exploit  a  wealth  of  data  on  a 
common  home  computer. 

With  the  great  strides  that  the  commercial  world  has  made  in  these  technologies,  the  public, 
ourselves  included,  has  great  expectations  for  our  software-intensive  defense  systems.  There 
have  been  some  successes;  and  there  have  been  some  problems.  Many  of  these  problems  are 
identified  in  a  report  by  the  House  Subcommittee  on  Investigations  and  Oversight  of  the 
House  Committee  on  Science,  Space,  and  Technology,  entitled  "Bugs  in  the  Program", 
September,  1989.  All  too  often,  software  is  delivered  late,  and/or  with  cost  overrun,  and/or 
does  not  work  the  way  it  is  supposed  to,  and/or  doesn’t  do  what  the  user  wanted.  According 
to  the  report,  we  end  up  paying  twice  for  the  software  -  once  to  develop  it  and  again  to  make 
it  work  the  way  it  was  supposed  to. 

On  the  surface,  it  looks  like  those  who  are  developing  software  for  Mission  Critical  Defense 
Systems  (MCDSs)  are  falling  short,  compared  to  those  who  develop  commercial  software 
products.  But,  there  is  a  big  difference: 

•  Software  for  Defense  Systems  is  usually  developed  to  meet  "a  user’s  needs",  which  are 
stated  in  the  requirements  specification, 

•  whereas,  the  primary  requirements  of  a  commercial  product  are  usually  that  it  offer 
a  general  capability,  and  that  it  be  marketable.  The  concept  of  developing  software 
to  "meet  the  requirement"  usually  does  not  exist. 

The  Department  of  Defense  is  probably  our  country’s  largest  buyer/developer  of  customer 
software.  Our  software  is  evaluated  on  the  battlefield,  not  the  marketplace.  Our 
requirements  are  completely  driven  by  the  user.  In  manner  that  is  timely  for  a  given  program 
we  must  capture  and  translate  our  customer’s  needs  into  a  system  that  helps  him  do  his  job 
better,  faster,  safer. 

Many  times,  our  users  do  not  know  how  to  express  what  it  is  that  they  want  or  they  are  not 
able  to  know  what  they  really  need,  during  the  time  that  we  allocate  for  recording  their 
requirements.  It  is  not  their  fault.  A  typical  user’s  job  is  to  do  his  job,  not  to  describe  it,  and 
not  to  describe  it  in  a  language  that  is  understandable  to  a  software  developer.  Because  of 
the  complexity  and  newness  of  the  systems  that  we  deal  with,  the  user  may  be  overwhelmed. 
After  acquisition  commitments,  he  often  comes  back  with  latent  insights  on  how  the  proposed 
automated  system  can  better  help  him.  These  new  requirements  are  sometimes  derived  from 
subsequent  experience  with  home  computer  technology.  Sometimes,  new  requirements  are 
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driven  by  changing  battlefield  realities.  Let’s  stop  blaming  the  user  for  changing  requirements 
and  find  a  way  of  developing  systems  and  software  despite  an  incomplete  and  changing  set 
of  requirements. 

In  reality,  not  a  lot  of  attention  has  been  given  to  the  requirements  problem.  (I  believe  that 
the  last  workshop  of  this  nature  took  place  in  Columbia,  Maryland,  in  1982.). 

That  is  why  we  are  here.  In  this  room,  we  have  a  group  of  people  who  recognize  that  there 
is  a  problem,  who  have  thought  about  it,  and  have  even  done  something  about  it. 

My  hope  for  us  is  to  bring  our  individual  efforts  into  focus  and  try  to  chart  our  course  for  the 
future. 

If  you  have  any  solutions  now,  let  us  know.  If  we  are  marching  in  the  wrong  direction,  let 
us  know.  Let  us  know  where  we  should  concentrate  our  efforts  over  the  next  2-3  years.  That 
is  our  job  over  the  next  2  days. 


10 


3 


WORKSHOP  PROCEEDINGS 


11 


This  page  is  intentionally  left  blank. 


12 


3  WORKSHOP  PROCEEDINGS 


3.1  Introduction 

By  the  year  2000,  it  is  projected  that  the  total  United  States  (US)  software  production  costs, 
which  have  been  growing  exponentially,  will  reach  $400  billion.  By  that  time,  the  Department 
of  Defense’s  (DoD’s)  annual  investment  will  be  $63  billion. 

Software  procurement,  development,  and  maintenance  are  critical.  Software  is  frequently 
cited  as  the  reason  for  many  systems  being  late,  over  budget,  and  not  fully  functional. 

As  much  as  fifty-five  (55)  percent  of  system  errors  are  introduced  during  the  requirements 
definition  phase.  This  is  when  the  needs  of  those  who  will  ultimately  be  affected  by  the 
system  are  captured  and  re-written  in  a  condensed  form  for  solicitation  and  then  later 
translated  into  a  form  that  is  best  understood  by  those  who  develop  the  software. 

Research  has  demonstrated  that  the  cost  of  solving  requirements-related  problems  increases 
drastically  with  the  time  it  takes  to  detect  an  error.  In  a  typical  sample  project,  the  estimated 
cost  to  fix  a  software  problem  (in  the  requirements  phase)  increased  from  a  factor  of  two  (2) 
to  a  factor  of  two-hundred  (200),  when  a  requirements-related  problem  was  not  noticed  until 
the  system  was  completed  and  installed. 

For  commercial  and  military  computer-based  systems  alike,  experience  has  shown  that, 
especially  for  large  and  complex  system  developments,  it  is  rare  that  the  true  needs  of  all 
stakeholders  are  fully  stated  and  understood  from  the  outset.  Furthermore,  even  the 
requirements  that  are  understood  are  not  always  agreed  upon  by  all  parties.  To  complicate 
matters  more,  requirements  that  have  been  documented  are  sometimes  subject  to 
interpretation  by  both  users  and  developers.  In  addition  to  these  problems,  once 
requirements  have  been  baselined,  there  are  difficulties  associated  with  anticipating, 
controlling,  and  managing  changes  to  the  baseline. 

The  above  is  a  result  of  the  lack  of  a  well-defined  Requirements  Engineering  (RE)  discipline 
which,  in  turn,  results  in  cost  overruns,  schedule  slippages,  poor  quality,  and  systems  that  fail 
to  satisfy  mission  needs. 

Requirements-related  problems  are  industry  wide,  not  unique  to  the  military.  Requirements 
must  not  be  merely  addressed.  They  must  be  engineered.  Accurate  and  timely  requirements 
formulation  and  management  is  a  skill,  yet  to  be  perfected. 

On  November  14-16  1989,  the  US  Army  Communications  Electronics  Command  (CECOM) 
Center  for  Software  Engineering  (CSE)  hosted  the  Requirements  Engineering  and  Rapid 
Prototyping  Workshop  in  Eatontown,  NJ.  This  event  was  sponsored  by  The  Technical 
Cooperation  Program’s  (TTCP’s)  XTP-2  Panel  on  Software  Engineering. 
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The  CECOM  Center  for  Software  Engineering  is  the  Center  of  Excellence  for  software 
engineering  support  to  designated  Array  Mission  Critical  Defense  Systems  (MCDSs).  It 
provides  software  en^neering  and  support  for  communication  and  electronics  systems,  from 
initial  system  concept  through  development,  deployment,  and  field  sustainment.  The  CECOM 
CSE  is  committed  to  worldwide  US  Army  readiness. 

The  TTCP  is  a  formal  arrangement  for  mutual  sharing  of  research  and  development 
resources/tasks  established  by  member  country  foreign  and  defense  ministries.  Member 
countries  include  Australia,  Canada,  New  Zealand,  the  United  Kingdom,  and  the  United 
States.  Within  the  structure  of  the  TTCP,  there  are  eleven  (11)  subgroups  made  up  of 
forty-four  (44)  working  panels  and  twenty-two  (22)  action  groups.  The  TTCP/XTP-2  Panel 
is  concerned  with  the  creation  and  life  cycle  support  of  software  for  defense-related 
applications. 

Many  of  the  workshop’s  forty-nine  (49)  international  participants  are  leading  experts  in 
Requirements  and  Software  Engineering.  They  met  to  share  current  information  on  the  Held, 
to  identify  and  clarify  the  most  pressing  issues,  and  to  provide  recommendations  to  DoD  for 
management,  development,  and  research  relating  to  Requirements  Engineering. 

The  workshop  provided  a  forum  for  thirteen  (13)  technical  presentations  by  leaders  in  the 
field.  The  workshop  participants  divided  into  three  (3)  working  groups  for  small-group 
interaction  on  central  issues.  One  working  group  addressed  the  Requirements  Engineering 
process  and  was  chaired  by  Dr.  Alan  Davis.  Another  dealt  with  requirements  engineering 
methodologies,  languages,  and  tools,  chaired  by  Dr.  Raymond  Yeh.  TTie  third,  chaired  by  Dr. 
Winston  Royce,  focussed  on  two  (2)  specific  aspects  of  Requirements  Engineering, 
knowledge-based  approaches  and  rapid  prototyping. 

The  workshop  was  chaired  by  Mr.  George  Sumrall  and  was  coordinated  by  Mr.  Harlan  Black, 
both  from  the  CECOM  Center  for  Software  Engineering.  Mr.  Black  is  responsible  for  the 
Center’s  efforts  in  Requirements  Engineering. 

These  Proceedings  document  the  presentations  and  findings  of  this  workshop  and  its  working 
groups. 
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3.2  Working  Group  1: 

Requirements  Engineering  Process 

Edited  by:  Dr.  Alan  M.  Davis,  Working  Group  Chair 

3.2.1  General  Information 


3.2.1 .1  Working  Group  Participants 


NAME 

EMPLOYER 

COUNTRY 

Andriole,  Stephen  J. 

George  Mason  University 

USA 

Batz,  Joseph 

DoD  Software  and  Computer  Technology 

USA 

Black,  Harlan 

CECOM  Center  for  Software  Engineering 

USA 

Charette,  Robert  N. 

ITABHI  Corporation 

USA 

Davis,  Alan  M. 

George  Mason  University 

USA 

Deutsch,  Michael 

Carnegie-Mellon  University  SEI 

USA 

Fink,  Robert  C. 

Performance  Resources,  Inc. 

USA 

Fountain,  Harrison 

Naval  Postgraduate  School 

USA 

Harris  Jr.,  Donald  C. 

US  Army  Air  Defense  Artillery  School 

USA 

Menell,  Raymond 

CECOM  Center  for  Software  Engineering 

USA 

Overmyer,  Scott  P, 

Contel  Technology  Center 

USA 

Podracky,  Mark  A. 

Digital  Fantacies  Limited 

USA 

Schlosser,  Edward  H. 

Lockheed  Software  Technology  Center 

USA 

Toher,  James 

SD-SCICON 

England 

White,  Douglas  A. 

Rome  Air  Development  Center 

USA 

3.2.1 .2  Roadmap:  A  Guide  to  Working  Group  1  Activities 


This  report  on  the  activities  of  Working  Group  1  is  divided  into  four  parts.  The 
introduction  identifies  seven  key  issues  crncerning  the  requirements  engineering  process. 
This  is  followed  by  a  section  on  four  (4)  of  the  most  critical  issues,  containing  for  each 
issue  an  analysis,  assumptions,  impact,  and  recommendations.  A  conclusion  summarizes 
the  recommendations  for  management  and  training,  development,  and  research.  This  is 
followed  by  a  glossary  of  key  terms. 
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3.2.1 .3 


Working  Group  Assignments 


Three  (3)  subgroups  were  formed  to  address  the  foremost  critical  issues.  Subgroup  1 
addressed  issue  1.  Subgroup  2  addressed  issues  2  and  4.  Subgroup  3  addressed  issue  3. 
Issues  5  through  7  were  not  further  analyzed.  The  members  of  the  working  group  and 
their  subgroup  assignments  were  the  following  distinguished  individuals; 


Subgroup  1 

Batz,  Joseph 
Black,  Harlan 
Charette,  Robert  N.  * 
Fink,  Robert  C. 
White,  Douglas  A. 


Subgroup  2 

Davis,  Alan  M. 
Deutsch,  Michael 
Fountain,  Harrison 
Ovemiyer,  Scott  P.  * 
Toher,  James 


Subgroup  3 

Andriole,  Stephen  J. 
Harris,  Donald  C. 
Menell,  Raymond 
Podracky,  Mark  A. 
Schlosser,  Edward  H.  * 


*  Subgroup  Chairperson 
3.2.2  Introduction 

The  first  of  the  three  working  groups  at  the  Workshop  addressed  issues  relating  to  the 
requirements  engineering  process.  A  requirements  engineering  process  defines: 

•  Each  of  the  individual  steps  to  create  and  enhance  requirements, 

•  The  partial  ordering  of  those  steps,  and 

•  The  overall  flow  of  information  among  those  steps. 

The  entire  process  is  independent  of  the  methods  and  tools  utilized  in  any  of  those  steps. 

Working  Group  1  identified  seven  key  issues  about  the  requirements  engineering  process. 
In  decreasing  order  of  importance,  they  are: 

1.  Uncertainty  and  change  are  difficult  to  cope  with. 

The  real  user  needs  are  rarely  well  understood  prior  to  system  deployment.  They 
are  certainly  not  well  understood  during  the  early  development  phases  when  we 
must  "baseline"  the  requirements.  The  result  is  that  our  perception  of  the 
requirements  constantly  changes  throughout  the  development  process. 

2.  Validation  of  requirements  is  critical  to  project  success. 

The  validation  of  a  to-be-established  baseline  traditionally  entails  a  detailed 
comparison  of  that  to-be-established  baseline  with  a  previously  established  baseline. 
In  practice,  that  previously  established  baseline  is  usually  the  requirements 
specification.  Thus,  for  example,  we  verify  the  design  documentation  by  comparing 
it  with  the  requirements.  Using  this  traditional  definition  of  validation,  we  now 
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have  a  significant  problem  with  respect  to  validating  the  requirements:  To  what  do 
we  compare  the  requirements?  The  current  practice  is  to  have  a  customer  sign  off 
on  the  requirements;  this  is  contractually  acceptable,  but  not  sufficient  in  achieving 
true  validation.  The  best  available  technique  today  might  be  the  use  of  a 
prototype. 

3.  Multiple  stakeholders  make  it  difficult  to  reach  closure. 

Many  individuals  with  many  diverse  backgrounds  have  a  stake  in  the  success  of  a 
project.  Most  have  opinions  concerning  what  the  requirements  are.  How  can  we 
accommodate  all  these  diverse  goals? 

4.  We  do  not  know  how  to  track  progress  in  requirements  development. 

We  all  know  of  the  famous  "99%  syndrome"  in  software  development  (i.e.,  it  takes 
25%  of  the  time  to  complete  the  first  99%  of  the  work,  and  75%  of  the  time  to 
complete  the  last  1%).  How  can  we  prevent  this  in  the  software  requirements 
specification  (SRS)?  The  industry  norm  today  is  that  we  simply  declare  the  SRS 
complete  when  it  looks  like  it’s  time  to  move  on  to  design. 

5.  Different  processes  are  needed  for  different  problems. 

There  does  not  exist  a  universal  process  model  for  requirements.  Each  class  of 
problem  requires  a  different  model. 

6.  Systems/Software/Requirements/Design  distinction  is  unclear. 

There  is  little  uniformity  in  the  industry  concerning  the  use  of  the  terms  "system 
requirements,"  "software  requirements,"  "system  design,"  "software  design,"  and 
"specifications."  But  it  is  more  than  a  semantic  problem.  During  each  of  the 
phases,  developers  regularly  violate  the  bounds  of  their  phase.  This  may  or  may 
not  be  detrimental,  but  it  must  be  understood. 

7.  The  existing  inventory  of  systems  needs  to  be  retrofitted  to  new  requirements 
engineering  technology. 

There  is  a  large  active  community  of  people  studying  and  performing  "reverse 
engineering"  to  the  huge  inventory  of  existing  software  systems.  These  people  are 
primarily  retrofitting  code  quality  into  systems  built  before  good  coding  principles 
became  well  understood.  As  we  learn  more  and  more  about  proper  requirements 
practices,  does  it  make  sense  to  retrofit  existing  systems  with  this  quality? 

3.2.3  Issues 

The  following  four  (4)  subsections  address  the  first  four  issues  described  above.  Three 
(3)  subgroups  were  formed  to  address  them.  Work  on  the  last  three  was  deferred,  due 
to  time  constraints. 
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3.2.3. 1  Uncertainty  and  Change  are  Difficult  to  Cope  With 


During  the  requirements  engineering  process,  we  are  repeatedly  faced  with  uncertainty. 
Are  the  requirements  correct?  Do  they  accurately  reflect  real  needs?  Can  a  system  be 
built  that  satisfies  these  requirements?  Is  it  possible  to  validate  that  a  system  meets  these 
requirements?  We  are  also  constantly  presented  with  changes.  User  needs  change.  Our 
perception  of  user  needs  changes.  Designers  discover  unsatisfiable  requirements.  Both 
uncertainty  and  change  introduce  significant  risk  into  the  system  development  and 
acquisition  process.  One  means  of  reducing  the  risks  associated  with  uncertainty  and 
change  is  evolutionary  acquisition.  In  this  approach,  we  acquire  a  system  in  increments. 
Each  increment  is  an  improved  superset  of  the  previous  increment’s  requirements  driven 
by  changing  needs.  Determination  of  these  additional  needs  can  be  accomplished  through 
a  variety  of  evolutionary  requirements  engineering  approaches  including  rapid  prototyping. 
Evolutionary  requirements  engineering  runs  counter  to  the  defense  system  acquisition 
"culture".  TTie  current  belief  that  all  system  requirements  can  be  specified  at  one  time  is 
deeply  embedded  in  DoD  standards  and  acquisition  policy. 

Unfortunately,  premature  freezing  of  requirements  specifications  may  lead  to: 

•  An  incomplete  understanding  of  true  system  requirements  (both  functional  and 
non-functional). 

•  An  incomplete  understanding  of  engineering  and  political  tradeoffs. 

•  The  addition  of  non-essential/unnecessaiy  requirements. 

•  The  inability  to  respond  adequately  to  external  changes  which  occur  in  the 
operational  context. 

The  last  item  is  of  critical  importance.  DoD  systems  are  expected  to  respond  to  a  wide 
variety  of  changing  circumstances,  some  within  DoD’s  control,  and  most  not.  These 
circumstances  create  new  system  requirements  unforeseen,  indeed  even  unpredictable,  at 
the  outset  of  system  acquisition.  These  requirements  are  driven  by  political  circumstances 
(e.g.,  changes  in  the  threat  or  in  domestic  funding),  changes  in  military  doctrine,  increased 
user  insight,  and  changing  technology.  The  result  is  that: 

•  Systems  are  3-5  generations  behind  currently  available  technology 

•  Systems  cannot  change  quickly  enough  to  meet  new  requirements  dictated  by  new 
operational  contexts. 

•  Many  systems  exhibit  poor  quality,  are  over  budget,  are  late,  and/or  fail  to  support 
the  required  mission. 

An  evolutionary  acquisition  process  will  mitigate  these  problems  considerably.  The  first 
phase  of  an  evolutionary  acquisition  process  defines  the  set  of  acceptable  requirements 
which  can  be  partitioned  into  an  incremental  build  of  the  system.  The  acceptable  set  of 
requirements  consists  of  all  requirements  which  are  perceived  as  being  necessary  (although 
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some  requirements  may  be  better  understood  than  others).  This  acceptable  set  is  called 
the  evolutionary  framework.  Using  Joint  Application  Development  (JAD), 
rapid-prototyping,  mock-ups,  etc.,  a  partitioned  subset  of  well-understood  requirements 
(i.e.,  generally  the  requirements  with  the  minimal  uncertainty)  is  constructed.  Once  this 
set  of  requirements  are  defined,  the  second  phase  of  the  evolutionary  process  occurs. 

The  requirements  of  an  evolutionary  framework  are  used  to  build  an  increment  of  the 
system.  An  appropriate  process  model  is  applied  to  further  refine  the  requirements.  Each 
increment  is  a  superset  of  the  previous  increment.  The  evolutionary  requirements  activity 
continues  through  the  life  of  the  system,  until  the  need  for  evolution  diminishes  to  near 
zero.  Along  the  way,  rapid  prototypes  are  used  to  validate  prospective  requirements  prior 
to  the  next  build.  This  helps  to  reduce  uncertainty  and  change,  and  thus  risk. 

3.2.3.1 .1  Sub-Issues 

There  are  several  management  and  technical  sub-issues  that  affect  the  feasibility  of 
evolutionary  acquisition.  The  management  sub-issues  are  as  follows: 

•  Current  acquisition  regulations  and  system  and  software  engineering  standards  such 
as  MIL-STD-490A  and  DOD-S'IT)-2167A,  encourage  the  early  binding  of 
requirements. 

•  Who  manages  the  evolutionary  requirements  activity?  There  needs  to  be  significant 
cooperation  here  between  contractor  and  Government  personnel.  Only  the 
Government  can  adequately  represent  the  needs  of  the  user  community.  Only  the 
contractor  can  understand  the  design  implications  of  requirements  evolution. 

•  The  acquisition  agency  must  be  aware  that  the  evolutionary  requirements 
engineering  activity  is  on-going,  and  as  such,  will  require  funding  and  deliverable 
schedules  which  are  subject  to  change.  Government  personnel  may  perceive  this 
approach  as  open-ended  and  counter  to  effective  cost  control,  schedule  control,  and 
other  resource  controls. 

The  technical  sub-issues  are  as  follows: 

•  How  can  we  partition  requirements  into  builds  that  make  technical  sense? 

•  The  initial  partition  of  requirements  must  be  "correct  enough"  to  serve  as  a  proper 
foundation  for  later  builds.  It  (and  the  initial  few  partitions)  also  must  be  of  a 
sufficient  breath  and  depth  to  gain  support  by  the  sponsoring  activity.  A  partition 
which  is  "too  small"  for  example,  may  not  show  "progress"  in  the  eyes  of  the 
acquisition  agency. 

•  We  must  use  methodologies  and  tools  which  will  support  incremental  acquisition. 
Methods  such  as  defined  within  the  U.S.  Navy  Research  Laboratory’s  Software  Cost 
Reduction  Project  is  an  example.  This  issue  is  related  to  the  sub-issue  concerning 
DOD-STD-2167A. 
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3.2.3.1.2  Assumptions 


The  following  are  the  assumptions  made: 

•  The  evolutionary  acquisition  approach  is  assumed  to  be  a  more  effective  and  lower 
risk  approach  than  other  current  approaches,  although  no  real  proof  is  available  to 
support  this  assumption. 

•  Partitions  are  subsets  of  the  entire  set  of  requirements.  Increments  are  the  portions 
of  the  prototype  that  implement  corresponding  requirements  partitions.  Partitions 
and  their  resultant  increments  must  occur  within  a  short  time-frame  to  minimize 
changes  to  the  next  partition  and  increment. 

•  Initially,  and  at  each  subsequent  stage,  a  stable  set  of  requirements  can  be 
established  and  partitioned. 

•  All  stakeholders  will  be  involved  in  the  partition  of  requirements  into  increments. 

3.2.3. 1.3  Impacts 

If  the  evolutionary  acquisition  approach  is  implemented,  we  believe: 

•  Uncertainty  concerning  requirements  will  be  reduced  because  uncertainty  is 
addressed  incrementally. 

•  Expectations  will  be  more  realistic. 

•  The  final  system  will  more  closely  meet  expectations. 

•  Risk  will  be  sharply  reduced. 

3.2.3.1 .4  Recommendations 

•  Management  and  Training. 

Make  changes  to  acquisition  policies,  acquisition  regulations,  and  DoD 
standards  to  facilitate  evolutionary  acquisition. 

Educate  contracting  officers  and  their  technical  representatives  on  this 
evolutionary  acquisition  approach.  Emphasize  that  system  requirements 
cannot  be  fully  defined  a  priori,  and  that  requirements  engineering  is 
continuous  throughout  the  life  of  the  system. 
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•  Development 

For  each  incremental  build  of  a  given  software  process  or  (in  DoD  terms) 
Computer  Software  Configuration  Item  (CSCI),  the  corresponding  defined 
partition  must  remain  frozen  during  the  implementation  of  that  build. 

•  Research 

Research  is  required  on  techniques  for  defining  acceptable  partitions  of 
requirements. 

Research  is  required  to  determine  if  the  evolutionary  acquisition  approach  is 
more  effective  than  others. 

Research  is  required  to  determine  how  to  define  partitions  in  such  a  way  that 
they  can  tolerate  the  inevitable  changes  that  will  occur. 

3.2.3. 1 .5  Validation  of  Requirements  is  Critical  to  Project  Success 

The  ability  to  determine  whether  documented  requirements  are  an  accurate  reflection  of 
actual  requirements  (i.e.,  the  real  user  needs)  is  crucial  to  the  success  of  any  software 
development  effort.  Often  requirements  content  is  heuristic  and  judgmental.  Many  of 
the  system  issues  addressed  by  requirements  have  no  apparent  right  answers.  In  most 
cases,  it  is  impossible  to  understand  the  real  requirements  without  the  presence  of  a 
working  system  in  the  users’  hands.  Since  most  acquisitions  do  not  include  up-front 
prototypes,  most  requirements  are  not  validated  in  any  way  until  after  system  deployment. 
An  acquisition  strategy  involving  prototyping  provides  an  early  system  on  which  multiple 
stakeholders  can  base  a  decision  concerning  system  suitability. 

The  validation  process  involves  identifying  the  guarantors  and  developing  validation 
statements.  For  any  single  system  there  can  be  many  guarantors  and  validation  statements 
of  varying  rigor  and  credence. 

3.2.3.1.6  Sub-Issues 

The  goal  of  requirements  validation  is  to  reconcile  documented  requirements  against  a 
referent  or  set  of  referents.  Realization  of  this  goal  substantially  reduces  the  risk  of  later 
breakage  of  the  software  or  hardware  architectures  caused  by  inaccurate  or  incomplete 
requirements.  This  goal  is  often  complicated  by  the  absence  of  a  referent.  The  sub-issues 
are: 

•  What  can  be  done  to  validate  requirements  when  no  referent  exists? 

•  How  can  we  validate  the  requirements  against  an  existent  referent? 
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3.2.3.1.7  Assumptions 


The  following  are  the  assumptions  made: 

•  Requirements  validation  is  possible. 

•  The  end  user  is  the  principal  stakeholder.  The  relative  importance  of  any 
stakeholders  is  contingent  upon  project  constraints  and  the  point  at  which  the 
stakeholder  enters  the  lifecycle  process. 

•  In  practice,  systems  are  often,  if  not  always,  accepted  without  validated 
requirements. 

•  Validation  is  a  dynamic  process  which,  in  concept,  may  never  end. 

3.2.3.1 .8  Impacts 

The  impacts  of  requirements  validation  are: 

•  decreased  likelihood  of  cost  overruns 

•  elimination  or  reduction  of  rework  and  schedule  slips 

•  lower  risk  of  development  (management,  schedule,  cost,  etc.) 

•  more  effective  systems. 

3.2.3.1.9  Recommendations 

•  Management  and  Training 

Remove  excessive  DoD  barriers  to  contractor  contact  with  users. 

Update  acquisition  policies  to  support  evolutionary  life  cycles. 

Increase  awareness  of  prototyping  methodologies. 

•  Development 

Develop  standardized  models  for  interdisciplinary  user/customer/contractor 
approach  to  requirements  validation. 

Construct  widespread  test  beds  (e.g..  Army  Interoperability  Network  --  AIN) 
and  associated  data  bases  in  more  applications  areas. 
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Research 


Perform  research  into  automating  the  synthesis  of  design  from  requirements. 

Develop  practical  formal  requirements  methods. 

3.2.3.2  Multiple  Stakeholders  Make  it  Difficult  to  Reach  Closure 

A  software-intensive  military  system  typically  is  employed  by  many  users  in  a  variety  of 
situations  and  contexts.  These  users,  situations,  and  contexts  all  provide  different 
viewpoints  for  determining  system  requirements.  Many  other  players  also  have  important 
stakes  in  the  success  of  the  system:  testers,  developers,  managers,  acquisition  personnel, 
configuration  management  personnel,  quality  assurance  personnel,  maintenance  personnel, 
etc.  The  current  DoD  requirements  process  often  fails  to  include  some  of  these 
viewpoints.  Conflicts  among  the  different  viewpoints  and  among  the  requirements  based 
on  them  is  often  unrecognized  or  inadequately  resolved.  All  of  this  leads  to  requirements 
that  are  incomplete,  inconsistent,  unrealistic,  or  misunderstood,  resulting  in  poor  quality 
systems  delivered  late  and  over  budget. 

3.2.3.2.1  Sub-Issues 

System  stakeholders  can  be  classified  as  those  who: 

a.  Affect  the  system 

b.  Are  affected  by  the  system 

c.  Both  affect  and  are  affected  by  the  system 

Potential  stakeholders  include  end-users,  proponents,  funders,  program  managers,  builders, 
testers,  and  system  maintainers.  Viewpoints  of  military  end-users  are  a  function  of  their 
level  or  echelon,  the  unit  mission  or  function,  and  their  experience  with 
automation/computerization.  Proponents  for  military  systems  are  charged  with  developing 
mission  requirements,  representing  the  end-user’s  viewpoint  throughout  the  development 
process,  and  defining  system  requirements.  Organizations  which  approve/control  funding 
clearly  are  stakeholders  in  the  system  requirements.  Program  managers,  their  support 
staffs,  and  their  contractors  who  build  systems  must  interpret  and  modify  requirements 
which  are  often  vague,  inconsistent,  and  incomplete.  Organizations  which  maintain  and 
extend  the  system  have  a  significant  stake  in  the  system  during  most  of  its  lifetime. 

Three  (3)  sub-issues  relate  to  the  multiple  stakeholders,  the  multiple  system  contexts,  and 
the  development  life  cycle  phases: 

•  How  can  we  resolve  the  disparate,  possibly  conflicting,  needs  and  views  of  the 
multiplicity  of  stakeholders? 
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•  How  can  we  resolve  the  disparate  needs  resulting  from  classes  of  users  who  must 
operate  with  the  system  in  multiple  contexts?  The  users  of  a  system  typically 
emanate  from  multiple  organizations.  These  organizations  have  different  missions 
and  different  battlefield  environments. 

•  How  can  we  resolve  the  needs  and  views  considering  that  they  are  changing 
constantly  over  time?  They  change  constantly  because  the  membership  of  the 
stakeholder  group  changes,  the  individual  people  themselves  change  as  they  learn 
and  grow,  and  the  requirements  specification  is  used  in  different  ways. 

3.2.3.2.2  Assumptions 
None  Identified. 

3.2.3.2.3  Impacts 

Reconciliation  of  stakeholders  viewpoints  would  result  in: 

•  Significantly  decreased  risk  of  user  dissatisfaction 

•  Less  cost  overruns  and  schedule  slippages 

•  Increased  productivity  (stakeholder  satisfaction  per  dollar) 

•  Increased  trust  among  stakeholders 

•  Decreased  risk  of  project  cancellation 

3.2.3.2.4  Recommendations 

Reconciling  divergent  requirements  perspectives  of  multiple  stakeholders  is  a  difficult 
problem.  It  will  require  the  cooperative  efforts  of  individuals  representing  all  significant 
viewpoints.  We  have  proposed  three  (3)  approaches.  They  are  ordered  from  the  easiest 
to  implement  to  the  most  difficult  to  implement.  Their  order  also  corresponds  to  the 
order  from  the  least  positive  impact  to  the  most  positive  impact. 

•  Develop  and  document  a  procedure  to  evaluate  and  rank  the  importance  of 
requirements  based  on  who  the  supportive  stakeholder  is. 

•  Expand  the  above  procedure  to  evaluate  and  rank  the  Importance  of  requirements 
based  on  the  motivations  and  purposes  expressed  by  the  supportive  stakeholder  as 
well  as  on  who  the  stakeholder  is. 
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•  Develop  and  document  a  procedure  that  can  be  used  to  capture  the  complete  set 
of  requirements,  as  follows: 

Identify  and  define  all  significant  viewpoints  and  stakeholders 

Determine  and  define  requirements  for  each  viewpoint 

Communicate  viewpoints  and  requirements  to  all  stakeholders 

Jointly  evaluate  requirements 

Negotiate  a  reasonable  requirements  envelope 

Test  the  requirements  envelope  continually 

Iterate  through  all  activities  until  system  retirement 

This  process  must  include  all  stakeholders  and  their  requirements.  Effective 
communication  of  the  viewpoints  and  requirements  depends  upon  a  combination  of  good 
documentation  and  face-to-face  refinement.  Requirements  should  be  evaluated  jointly 
with  respect  to  priority,  volatility,  consistency,  feasibility.  The  concept  of  a  "requirements 
envelope"  is  key.  We  believe  that  a  single,  completely  consistent  requirements  set  may 
be  unattainable  in  many  cases.  It  may  also  result  in  overly  constrained  requirements, 
leading  towards  a  less  adaptable  system  architecture.  The  goal  is  to  achieve  a  consensus 
requirements  envelope  that  reduces,  but  does  not  eliminate,  variety  and  inconsistency. 
A  good  requirements  envelope  will  focus  the  requirements  sufficiently  to  satisfy  current 
requirement  perceptions  without  overly  constraining  them.  The  requirements  envelope 
should  include  measures  of  priority  and  volatility.  The  process  should  test  the 
requirements  envelope  continually,  by  testing,  simulation,  prototyping,  and  partial  system 
deliveries. 

Further  specific  recommendations  are: 

•  Management  and  Training 

Acknowledge  the  importance  of  multiple  requirements  perspectives. 
Management  should  require  formal  recognition  of  multiple  stakeholders 
requirements  perspectives,  and  expand  the  requirements  analysis  and 
prototyping  phases  to  include  these. 

Enhance  life  cycle  models  to  accommodate  deeper  requirements  analysis  and 
modeling  of  the  interrelationships  among  requirements. 


25 


Development 


Develop  a  set  of  software  tools  to  support  "multiple  stakeholder  requirements 
perspectives"  analysis.  The  tools  should  consist  of  user  taxonomies  of 
organizations,  and  methods  for  conducting  requirements  trade-off  analysis. 

Apply  the  new  methods  and  tools  developed  above  to  real  applications. 

•  Research 

Develop  models  to  capture  multiple  stakeholder  requirements. 

Develop  and  apply  new  methods  for  trade-off  among  competing  and 
conflicting  requirements.  Risk-based  decision  techniques  such  as 
multi-attribute  utility,  classic  cost-benefit,  and  Pareto  optimization  techniques, 
among  others,  can  be  used  in  this  arena. 

3.2.3.3  We  Do  Not  Know  How  to  Track  Progress  in  Requirements  Development 

Progress  metrics  for  the  requirements  process  differ  markedly  from  production  oriented 
process  metrics  because  there  is  no  clear  end  point.  Requirements  engineering  is  a 
continuing  process  based  on  exploration  and  discovery,  often  creating  unexpected 
iterations.  Nonetheless,  some  subjective  oriented  indicators  of  progress  are  possible. 

3.2.3.3.1  Sub-Issues 

The  following  sub-issues  bear  on  the  problem: 

•  A  technical  feasibility  indicator  for  implementing  a  requirements  set  is  a  desirable 
measure. 

•  A  cost/schedule  feasibility  indicator  for  a  requirements  set  is  a  desirable  measure. 

•  The  contractual/political  environment  does  not  accept  that  exploratory  processes 
have  a  built-in  level  of  backtracking  and  iteration. 

•  We  are  dealing  with  a  Judgmental,  discovery  driven  process  with  no  clear  end-point. 

•  Progress  is  not  necessarily  monotonic.  Time/schedule  is,  therefore,  often  a  poor 
metric. 
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3.2.3.3.2  Assumptions 

The  following  assumptions  are  made: 


•  Progress  can  be  observed,  but  not  necessarily  measured  in  an  objective  fashion. 

•  An  agreeable  metric  of  progress  is  possible. 

•  Progress  is  not  necessarily  a  linear  or  well-behaved  function. 

•  Risk  (as  to  technological  feasibility  and  cost/schedule)  can  be  assessed  periodically 
and  thereafter  monitored. 

3.2.3.3.3  Impacts 

The  impacts  of  measuring  requirements  progress  are: 

•  An  appropriate  definition  of  progress  that  can  substantially  reduce  risk 

•  Measurable  progress  observations  that  aid/feed  the  requirements  development  and 
validation  process 

•  Well-thought  out,  accurate  requirements 

•  Reduction  of  arbitrary  and/or  autocratic  decisions  concerning  the  completion  of  the 
requirements  baseline 

•  Decriminalization  of  early  problem  recognition  and  correction. 

3.2.3.3.4  Recommendations 

•  Management  and  Training 

Current  contracts  often  .encourage  the  early  freezing  of  requirements  and 
discourage  subsequent  changes  to  those  requirements.  Award  fee  structures 
on  contracts  should  be  modified  to  encourage  the  creation  and  timeliness  of 
requirements  specifications. 

Develop  a  team  approach  to  help  reduce  unrealistic  expectations  on  the  part 
of  the  user/customer. 

Educate  program  managers  and  team  members  that  "changing  your  mind"  as 
a  result  of  new  information  is  acceptable. 

Train  Government  program  managers  in  the  use  of  acquisition  models  that 
employ  prototyping. 
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•  Development 

Apply  the  new  metrics  developed  above  on  actual  projects. 

Develop  an  explicit  requirements  validation  plan  for  every  project 

•  Research 

Develop  and  use  effective  metrics  to  measure  requirements  progress  and 
completioiL 

Develop  more  rigorous  risk  assessment  and  risk  management  techniques. 
3.2.4  Conclusion 

In  this  section,  we  summarize  the  recommendations  of  Working  Group  1: 

3.2.4.1  Management  and  Training 

■  Change  acquisition  policies  to  accommodate  evolutionary  acquisition. 

•  Educate  all  stakeholders  on  various  acquisition  alternatives  such  as  the  evolutionary 
acquisition  model 

•  Train  all  stakeholders  on  the  value  and  role  of  prototyping  in  the  s>’stem  life  cycle. 

•  Involve  all  stakeholders  in  requirements; 

Determination 

Validation 

•  Realign  incentives/milestones  to  more  easily  capture  requirements  "progress". 

•  Introduce  risk-based  decision  making. 

•  Reduce  DoD  barriers  to  developer-user  interaction. 

3.2.4.2  Development 

•  Freeze  requirements  in  small  incremental  builds. 

•  Develop  more  testbeds  like  AIN  to  validate  interoperability  earlier  in  the 
development  process. 
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3.2.4.3  Research 


•  Develop  new  techniques  to  isolate  acceptable  requirements  partitions. 

•  Develop  new  techniques  to  accommodate  change  in  requirements  and  designs. 

•  Develop  and  reGne  practical  formal  requirements  techniques. 

•  DeGne  a  multt-stakeholder  requirements  process. 

•  Develop  thorough  understanding  of  requirements  "normalization."  Somewhat 
analogous  to  database  normalization,  this  envisioned  technique  would  enable  two 
sets  of  requirements  to  be  shown  to  be  equivalent 

•  DeGne  and  understand  requirements  process  models. 

•  DeGne  and  understand  models  of  requirements  progress. 

•  Perform  experiments  to  determine  what  conditions  make  evolutionary  acquisition 
and  prototyping  practical. 

•  Develop  tools/techniques  to  capture  merits/tradeoffs  among  requirements. 

3.2.5  Glossary 

Requirements  SpeciGcation  -A  requirements  specification  is  a  document  containing  all  the 
requirements  for  a  system. 

•  A  requirements  speciGcation  is  complete  if  everything  that  all  the  eventual 
stakeholders  (customers,  users,  etc.)  want  is  specified. 

•  A  requirements  specification  is  consistent  if  no  two  subsets  of  requirements  conflict. 

•  A  requirements  specification  is  unambi^ous  if  every  one  of  its  requirements  has 
only  one  possible  interpretation. 

Guarantor  -  The  guarantor  is  the  group  of  stakeholders  who  are  the  final  authority  on  the 
sanctioning  of  the  requirements  and  the  validation  statements. 

Prototype  -  A  prototype  is  a  partial  implementation  of  a  system  constructed  primarily  to 
enable  customers,  users,  or  developers  to  learn  more  about  a  problem  or  its  solution. 

Referent  -  A  referent  is  a  baseline  (such  as  a  requirements  specification  document)  to 
which  we  compare  the  requirements  for  validation. 

Stakeholder  -  A  stakeholder  is  an  individual,  group,  organization  or  system  which  can 
influence  or  be  influenced  by  the  computer  system. 
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Validation  Principle  -  A  validation  principle  is  the  accepted  warrant  that  is  appealed  to 
in  order  to  justify  the  validation  process. 

Validation  Statements  •  Validation  statements  constitute  the  rationale  or  proof  that 
connects  the  requirements  to  their  referent  Some  participants  maintained  that  a 
complete  proof  for  a  requirements  set  is  impossible. 
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3.3  Working  Group  2: 

Requirements  Engineering  Methodoiogy,  Tools,  and  Languages 

Edited  by:  Dr.  Raymond  T.  Yeh,  Working  Group  Chair,  with  Dr.  William  Gilmore. 

3.3.1  General  Information 

3.3.1 .1  Working  Group  Participants 
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COUNTRY 

Comer,  Edward  R. 

Software  Productivity  Solutions,  Inc. 

USA 

Fisher,  Gary  E. 

National  Institute  of  Standards  and  Technology 

USA 

Gilmore,  William 

International  Software  Systems,  Inc. 

USA 

Hamilton,  Margaret 

Hamilton  Technologies,  Inc. 

USA 

Harris,  Robert  L. 

Wright  Patterson  Air  Force  Base 

USA 

Hsia,  Pei 

University  of  Texas  at  Arlington 

USA 

Labbe,  Jean-Claude 

Defence  Research  Establishment  (Valcartier) 

Canada 

Larson,  Aaron 

Honeywell/Systems  and  Research  Center 

USA 

Looney,  Michael  J. 

Admiralty  Research  Establishment 

England 

Manley,  Gary 

Naval  Postgraduate  School 

USA 

Marks,  Walter 

CECOM  Center  for  Software  Engineering 

USA 

Ng,  Peter 

New  Jersey  Institute  of  Technology 

USA 

Racine,  Glenn  E. 

AIRMICS 

USA 

Rzepka,  William 

Rome  Air  Development  Center 

USA 

Samson,  Donaldine 

Sonex  Enterprises,  Inc. 

USA 

Singer,  Carl  A. 

Bellcore 

USA 

Tanik,  Murat  M. 

Southern  Methodist  University 

USA 

Yeh,  Raymond  T. 

International  Software  Systems,  Inc. 

USA 

Roadmap:  A  Guide  to  Working  Group  2  Activities 

This  report  on  the  activities  of  Working  Group  2  consists  of  four  parts. 

The  introduction 

presents  the  group’s  approach  of  dividing  into  four  subgroups,  one  each  for  methodology, 
tools,  languages,  and  integration.  It  summarizes  the  major  issues  the  working  group 
addressed  as  well  as  the  major  recommendations  it  proposed,  covering  policy  and 
management,  development,  and  research.  Next  follows  a  section  on  methods  and  tools, 
which  addresses  the  six  interdependent  subprocesses  that,  according  to  the  group,  best 
describe  the  requirements  engineering  process.  For  each  subprocess,  discussion  is 
provided  on  the  activities,  methods,  and  tools  that  apply  to  it;  an  analysis  of  the  problems 
and  issues  that  occur  within  it;  and  recommendations.  Activities  across  all  subprocesses 
are  addressed  at  the  end  of  this  section.  The  language  section  follows,  focussing  on 
problems  and  issues,  objectives,  features  of  existing  languages,  and  recommendations.  The 
report  concludes  with  a  glossary  of  key  terms. 
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3.3.1 .3  Working  Group  Assignments 


The  distinguished  participants  of  Working  Group  2  are  divided  into  the  following 
subgroups: 


Methodology  Tools 


Languages 


Integration 


Gilmore,  William 
Harris,  Robert  L. 
Hsia,  Pei* 

Ng,  Peter 

Samson,  Donaldine 
Singer,  Garl  A. 


Comer,  Edward  R. 
Looney,  Michael  J. 
Manley,  Gary 
Marks,  Walter 
Racine,  Glenn  E. 
Rzepka,  William* 


Fisher,  Gary  E. 
Hamilton,  Margaret* 
Labbe,  Jean-Claude 
Larson,  Aaron 
Tanik,  Murat  M. 


Comer,  Edward  R. 
Gilmore,  William 
Samson,  Donaldine 
Yeh,  Raymond  T.* 


^Subgroup  chairperson. 


Acknowledgment:  The  whole  group  wishes  to  thank  COMCON,  Inc.,  especially  Diane 
Alexander,  for  their  extensive  support  and  technical  contributions, 

3,3.2  Introduction 

Requirements  engineering  is  a  new,  vital  frontier  for  software  research.  Several 
organizations  are  researching  and  developing  requirements  engineering  processes.  These 
processes  are  only  practical  and  cost-effective  when  supported  by  the  appropriate 
methodologies,  language,  and  tools.  Many  software  engineering  tools  and  methodologies 
have  been  developed  to  solve  parts  of  the  software  engineering  problem.  But  the 
methodologies,  languages,  and  tools  for  software  requirements  have  not  received  adequate 
emphasis  in  an  integrated  sense  for  a  complete  requirements  process. 

Requirements  engineering  methodologies,  languages,  and  tools  are  support  mechanisms 
for  any  requirements  engineering  process.  The  objective  of  Working  Group  2  was  to 
investigate  specific  mechanisms  relating  to  a  full  spectrum  of  activities  within  the 
requirements  engineering  process. 

Working  Group  2  initially  assumed  that  the  requirements  process  is  extensive  over  time 
and  in  level  of  detail,  i.e.,  it  may  include  generations  of  systems  and  broad  domain 
analysis,  as  well  as  detailed  systems  specifications  concerning  user  needs.  Furthermore, 
it  was  assumed  that  the  process  is  intertwined  with  the  overall  system  evolution  and  has 
the  following  six  generic  sub-processes: 

1.  Context  Analysis  -  analysis  of  problem  space  and  application  domain;  deals  with 
description  of  problems  only,  not  solutions. 

2.  Objective  Analysis  -  analysis  of  the  solution  space,  and  system  objectives  for  life 
time  use. 
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3.  Requirements  Determination  •  specification  of  characteristics  the  system  must  meet 
to  satisfy  user  needs. 

4.  Requirements  Analysis  -  analysis  of  expressed  requirements;  includes  related 
refinement,  elaboration,  and  correction. 

5.  Synthesis  -  formation  of  a  cohesive  specification  from  the  detailed  analyses;  involves 
integration  of  partitioned  analyses  occurring  due  to  problem  complexity  and 
breadth. 

6.  Validation  -  ensuring  that  the  expressed  requirements  match  real  user  needs  and 
constraints. 

These  six  generic  requirements  sub-processes  do  not  necessarily  occur  sequentially,  and 
are  interdependent.  Furthermore,  the  support  mechanisms,  which  are  methodology,  tools, 
and  languages,  are  interdependent. 

The  Working  Group  2  approach  was  to  break  into  individual  analysis  groups,  one  each 
for  methodology,  tools,  and  languages,  and  a  fourth  specifically  for  integration. 
Intermittent  synthesis  occurred  by  collective  meetings  and  was  catalyzed  by  the  integration 
subgroup. 

In  order  to  analyze  the  support  mechanisms,  the  subgroups  were  tasked  with  identifying 
specific  activities  associated  with  each  sub-process,  and  identifying  specific  support 
mechanisms  for  these  activities  and  sub-processes.  Some  of  the  activities,  such  as 
prototyping,  span  more  than  one  sub-process.  Detailed  analyses  for  each  sub-process  are 
presented  in  individual  sub-sections  in  this  report. 

The  language  analysis  is  presented  in  a  separate  section  because  the  Language  subgroup 
felt  that  language  support  integrates  with  the  other  areas  in  a  broad  way.  The  Language 
subgroup  analyzed  requirements  for  a  common  requirements  language  schema. 

3.3.2.1  Major  Issues 

The  following  major  issues  surfaced  during  subgroup  analysis  and  synthesis: 

•  Policy  and  Management  Issues: 

There  is  lack  of  widespread  awareness  of  the  importance  of  requirements 
engineering,  especially  in  management  and  acquisition  offices. 

There  is  a  lack  of  emphasis  for  the  requirements  process  throughout  the  life 
cycle,  and  for  its  related  policy  and  funding  support. 

There  is  general  unawareness  that  requirements  engineering  is  vital  to  system 
success,  and  hence  to  national  security  and  economic  vitality. 
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Development  and  Research  Issue 


Currently  used  languages  and  methods  fail  to  capture  requirements 
information  to  effectively  enable  system  evolution. 

Lack  of  understanding  of  the  so-called  "non-functional"  requirements  - 
performance,  reliability,  maintainability,  security,  safety,  etc. 

Tools  are  not  integrated  to  support  the  widespread  needs  of  the  requirements 
process. 

Lack  of  effective  means  to  salvage  large  investment  in  current,  large  software 
systems. 

Lack  of  understanding  of  what  to  measure  and  how  to  measure  key 
requirements  process  parameters. 

3.3.2.2  Major  Recommendations 

Major  recommendations  developed  by  Working  Group  2  are  as  follows: 

•  Policy  and  Management  Issues 

Change  acquisition  policies  and  management  practice  to  support  a 
requirements  -  centered  development  life  cycle  model. 

Increase  training  of  management/acquisition  personnel  in  requirements 
engineering. 

Establish  an  information/consultation  center  on  requirements  engineering 
(process,  methods,  tools,  and  metrics). 

Reallocate  currently  available  funds  supporting  downstream  software  activities 
to  requirements  engineering  activities,  (i.e.,  concentrate  more  resources  on 
identifying  and  confirming  what  is  to  be  built,  rather  than  on  how  to  build  it). 

•  Development  and  Research  Recommendations: 

Develop  wide  spectrum  language  to  support  acquisition,  representation,  and 
reuse  of  requirements  information  and  its  related  knowledge. 

Develop  methods  to  capture,  integrate,  and  measure  the  so-called 
non-functional  requirements. 

Develop  an  integrated  environment  of  requirements  engineering  tools. 

Develop  methods  and  tools  to  support  reverse  engineering  of  current  systems 
that  are  able  to  be  modernized. 
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Determine  and  develop  meaningful  metrics  supporting  modern  requirements 
engineering  practice. 


3.3.3  Methods  and  Tools  Support  for  the  Requirements  Process 

This  section  presents  the  detailed  results  of  analyzing  the  six  generic  requirements 
sub-processes.  Each  sub-process  was  analyzed  for  the  following: 

•  The  detailed  activities  that  are  components  of  that  subprocess,  methods  for 
performing  the  activities,  software  tools  that  assist  in  performing  the  activities 
(presented  in  a  table  and  related  discussion); 

•  Problems  and  issues  concerning  methods  and  tools;  and 

•  Recommendations  and  research  areas  concerning  the  methods  and  tools. 

Recall  that  the  six  generic  requirements  engineering  subprocesses  are: 

Context  Analysis 
Objective  Analysis 
Requirements  Determination 
Requirements  Analysis 
Synthesis 
Validation 

3.3, 3.1  Context  Analysis 

Context  analysis  involves  analysis  of  the  problem  space  and  application  domain  of  a 
potential  system  to  be  developed.  It  deals  with  description  of  problems  only,  not 
solutions.  (See  Table  1.) 


3.3.3.1.1  Discussion 

Context  analysis  is  a  general  activity  under  which  four  major  sub-activities  were  identified. 
Requirements  are  those  defined  and  derived  from  the  "setting"  within  which  the  system 
must  operate. 

Identification  of  the  problem  space  boundaries  is  important  for  understanding  the 
environmental  constraints  under  which  systems  will  be  developed,  operated,  and  evolved. 
Methods  for  performing  this  activity  include  document  reviews  (mission,  scenerios,  and 
higher-level  requirement  statements  of  existing  systems),  interviews  with  potential  users, 
market  analysis,  and  policy  guidelines.  People  involved  include  decision-makers  and 
potential  users.  System  environment  identification  also  includes  the  physical,  functional, 
economic,  social,  and  cultural  parameters  that  will  be  associated  with  or  that  affect 
requirements. 
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Table  1.  Activities,  methods,  and  tools  for  context  analysis 


Activities  Identify  problem  space  boundaries; 
political 
cultural 
legal 

resources  (material,  human,  informational,  financial) 
organizational  policies  and  procedures 
technological  scope 

Needs  identification: 

identify  market  needs  and  trends 

threat  assessment 

problems  with  current  systems 

identify  the  common  needs  of  different  organizations 

Application  modeling 

enterprise  modeling 
mission  modeling 
identify  information  resources 

Postulating  solutions 

Methods  Interview 

Document  Reviews 
Conceptual  Modeling 
Delphi 

Group  Decision  Support 
Analysis 

Surveying  Current  Systems 

Observation 

Role-Playing 

Walk-through 

Gaming 

Tools  Concept  Modeling  Tools,  e.g.: 

P-Tech 

Knowledge  Engineering  Tools,  e.g.: 

Expert  System  Shells,  Prolog 

Enterprise  Modeling,  e.g.: 

Entity-Relationship  Models,  Activity  Models,  Behavior  Models 
Simulation  Models 


A  second  major  sub-activity  involves  needs  identification.  This  includes  interviews  with 
users  of  existing  systems,  customer  questionnaires,  reviews  of  official  needs  documents  and 
statements  of  needs  from  customers,  and  market  surveys.  Support  methods  also  include 
"Delphi",  modeling,  and  critiquing  of  existing  systems. 

A  third  major  sub-activity  identified  is  application  modeling.  This  involves  spelling  out 
those  effects  governed  by  the  surrounding  user’s  community  that  will  affect  requirements. 
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It  may  involve  modeling  the  general  user  requirements  at  a  meta-system  level,  using 
enterprise  modeling  tools.  Such  models  should  project  future  changes.  Personal 
interviews  and  review  of  materials  concerning  the  user’s  environments  provide 
information.  Participants  include  the  customer/user.  How  the  system  will  be  maintained 
is  an  important  consideration  that  feeds  this  activity.  The  system  should  be  considered 
from  the  viewpoint  of  the  business  and  its  procedures  and  structure/organization.  This 
leads  to  consideration  of  the  Tiusiness"  working  methods  and  related  ramifications  in 
terms  of  need/change. 

A  fourth  major  activity  is  postulating  solutions.  It  is  performed  not  so  much  to  identify 
solutions  as  to  help  clarify  the  problem.  This  activity  may  involve  surveying  technology, 
conceptual  modeling,  and  gaming.  Concept  modeling  and  simulation  tools  support  this 
activity. 

3.3.3.1.2  Problems  and  Issues 

The  context  analysis  phase  requires  the  management  of  many  pieces  of  informal 
information.  This  information  is  dynamic  and  unstable  and  so  it  requires  flexible  tools. 

The  problems  with  these  can  be  generally  categorized  as  being  too  removed  from  those 
specifying  the  requirements  and  being  too  complex  for  them  to  make  good  use  of  the 
capabilities.  The  information  being  captured  is  in  a  large  number  of  cases  too  general  or 
informal.  Most  of  the  tools  are  static  and  require  extensive  resources  both  in  terms  of 
manpower  and  computers  to  simulate  "world  models"  and  provide  meaningful  outputs 
rather  than  the  obvious. 

3.3.3.1 .3  Recommendations  and  Research  Areas 

This  relatively  infant  sub-process  needs  extensive  modeling  in  a  number  of  areas  to 
provide  a  base  of  support.  Initially  it  should  be  supported  by  R&D.  Modeling  will  involve 
knowledge  acquisition  and  representation,  and  utilize  common  structured  knowledge. 
Further  research  is  needed  regarding  elicitation  techniques. 

Further  support  for  multiple  domain  analyses  is  also  needed,  and  these  should  model 
adaptation,  change,  what-if  scenarios,  and  sensitivity  analyses. 

3.3.3.2  Objective  Analysis 

Objective  analysis  involves  analysis  of  the  solution  space,  and  system  objectives  for  lifetime 
use.  (See  Table  2.) 

3.3.3.2.1  Discussion 

This  activity  focuses  on  defining  the  "mission-level"  requirements  of  a  system.  Definition 
as  to  how  the  system  will  satisfy  user  needs  over  the  long-term  is  captured  and  refined. 
Therefore,  the  activities  listed  in  Table  2  are  intended  to  focus  on  defining  (and  later 
revising)  the  high-level,  long-term  objectives  that  the  system,  and  all  aspects  related  to  its 
evolution,  should  satisfy. 
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Table  2.  Activities,  methods,  and  tools  for  objective  analysis 


Activities  Define  specific  problem  to  be  solved 

Define  system/environment  boundary  and  interface 

Define  life  cycle  profiie; 
length  of  use 
expected  breadth  of  use 
desired  Return  On  investment 

Define  user  profile: 

frequency  of  use 
education/experience  of  user 

Identify  non-functional  requirements; 

necessary  reliability,  security,  performance,  etc. 

Identify  critical  success  factors; 

prioritize  major  objectives 

Identify  operational  capabilities: 

basic  needed  functions  of  the  target  system 
determine  wish  lists  of  major  objectives 

Conduct  feasibility  analysis 

physical/technical,  financial,  political,  cultural 

Uncertainty  and  risk  assessments  for  major  objectives 

Perform  trade-off  analysis  of  major  objectives 

Methods  Interview 

Documention  Review 

Trade-off  Analysis 

modeling,  role-playing 

Build  scenarios  of  high  level  system  usages,  possibilities 

Delphi  techniques 

Group  decision  support  methods 

Tools  Conceptual  Modeling  Tools 

Knowledge  Engineering  Tools 
Enterprise  Modeling  Tools 
Security  Models 
Reliability  Models 
Formal  Verification  Tools 


In  addition  to  identifying  the  system/boundary  interface,  operational  capabilities,  and 
analyzing  feasibility  regarding  technical,  operational,  and  economic  factors,  there  is  other 
important  information  to  gather.  There  is  need  to  identify  the  expected  breadth  of  use, 
and  long-term  time  and  economic  scope  of  the  new  system.  This  includes  developing  a 
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long-term  plan  and  an  acquisition  scheme,  including  a  scenario  of  planned  yearly  goals, 
and  a  projection  of  the  kinds  of  contracts  to  be  used.  It  should  also  identify  the 
anticipated  evolution  of  the  new  system,  i.e.,  is  the  system  expected  to  support  a  static  or 
dynamic  environment.  Toward  this  end  it  is  particularly  important  to  identify  the  critical 
success  factors  for  primary  decision-makers  who  will  use  the  new  system  (this  promotes 
estimates  of  Return  on  Investment  (ROI)  for  the  project,  and  trade-off  analyses). 

In  addition,  there  is  need  to  identify  the  resources  for  information  contributing  to 
requirements  determination.  This  may  involve  creation  of  a  plan  for  who,  generically, 
should  participate,  and  how  to  sustain  continuity  of  expertise  over  the  whole  life  cycle. 

Activities  also  include  identification  of  constraints,  especially  with  respect  to  policy 
constraints  levied  by  government  by  economic  realities,  current  market  conditions,  or 
availability  of  resources.  Schedule  is  also  a  constraint  in  terms  of  meeting  a  "window  of 
opportunity". 

Finally,  we  note  that  non-functional  requirements  concern  reliability,  security, 
maintainability,  extensibility,  etc.  Allocation  of  priorities  to  objectives  is  also  done.  In 
order  to  prepare  for  work  in  deciding  among  alternatives,  evaluation  criteria  called 
alternatives  metrics  must  be  considered. 

People  involved  in  the  objective  analysis  process  include  experienced  user  and  domain 
specialists  (e.g..  Training  and  Doctrine  Command  (TRADOC)  people  in  the  army),  system 
architects  (e.g.,  industry  experts),  operations  research  analysts,  financial  analysts,  and 
policy  makers. 

Applicable  tools  during  objective  analysis  include  those  tools  which  were  used  during 
context  analysis.  In  addition,  modeling  tools,  which  help  with  some  non-functional 
requirements  have  been  developed.  For  example,  security  models,  formal  verification 
systems,  and  reliability  modeling  tools  now  exist. 

3.3.3.2.2  Problems  and  Issues 

In  general,  the  problems  with  modeling  tools  here  concern  their  limited  applicability,  e.g., 
security  modeling  addresses  a  very  big  problem  but  in  a  very  narrow  domain  of 
applicability.  In  addition,  these  modeling  tools  fail  to  scale  up  to  realistically  sized 
systems.  In  some  cases,  especially  the  reliability  models,  credibility  of  the  results  is  an 
issue. 

3.3.3.2.3  Recommendations  and  Research  Areas 

There  needs  to  be  R&D  for  how  to  specify  non-functional  requirements.  In  particular, 
we  need  methods  and  tools  to 

•  Support  conflict  resolution,  e.g.,  maintainability  vs.  reliability, 

•  Enable  specifying  "degree  of,  e.g.,  quantifying,  such  as  levels  of  security. 
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•  Help  identify  relationships  among  the  "ilities", 

•  Model  with  wide  applicability,  e.g.,  scale  up  kinds  of  current  modeling, 

In  addition,  we  need  R&D  to  learn  how  to  do  more  relevant  workload  modeling,  analysis, 
and  simulation. 

3.3.3.3  Requirements  Determination 

Requirements  Determination  involves  specification  of  characteristics  the  system  must  meet 
to  satisfy  user  needs.  (See  Table  3.) 

3.3.3.3.1  Discussion 

The  requirements  determination  activity  uses  and  analyzes  the  gathered  information  from 
context  and  objectives  analyses  (goals,  objectives,  and  needs)  to  create  a  comprehensive 
list  of  requirements  for  the  system  to  be  developed.  Alternatives  are  identified  and 
evaluated.  For  each  alternative  under  study,  a  feasibility  study  must  be  performed  to 
assess  the  ability  of  the  sponsoring  organization  to  develop  the  alternative,  technically  and 
with  respect  to  available  resources.  This  activity  also  involves  on-going  revision  and 
evolution  of  such  requirements. 

In  general,  requirements  can  be  classified  as  either  functional  or  non-functional,  although 
there  is  substantial  interdependence.  Non-functional  requirements  traditionally  refer  to 
constraints,  necessities  in  performance  and  security,  and  the  "ilities"  such  as  quality, 
reliability,  availability,  maintainability,  etc.  The  satisfaction  of  many  non-functional 
requirements  depends  on  whether  and  how  certain  functional  requirements  are  met. 

Methods  focus  on  investigation  through  the  building  and  examination  of  prototypes 
(functional/operational)  to  understand  the  requirements  in-depth.  Generally,  the 
combined  set  is  not  easily  comprehended  without  some  form  of  realistic  viewing  or  testing. 
Investigation  is  also  supported  by  interviews  with  customer/user/management-personnel 
(who  have  been  identified  in  the  phase  of  context  analysis),  and  by  document  review  and 
feedback  of  information  among  the  role  players. 

Specification  methods,  such  as  data  flow  and  object-oriented,  help  thinking  through  the 
problem  and  characterizing  the  functional  requirements  for  communication.  Templating 
supports  the  capture  and  description  of  non-functional  requirements.  The  techniques  of 
n^  charting  and  modeling,  in  association  with  prototyping,  support  trade-off  analyses. 

Among  existing  tools  that  deal  with  requirements  determination  are  the  range  of  currently 
available  requirements  modeling  tools  which  support  data  flow  diagrams,  functional 
decomposition,  state-transition  diagrams,  entity  relationship  diagrams,  petri-nets,  stimulus 
response  networks,  etc.  Other  tools  that  are  applicable  here,  especially  for  determining 
the  feasibility  of  alternatives,  include  model  development  tools  for  analytical  models, 
simulation  models  and  cost  models.  In  the  area  of  simulation  models,  some  success  has 
been  gained  by  "tuning"  or  "tailoring"  a  model  to  a  very  narrow  and  specific  application 
domain  so  that  its  results  are  produced  with  greater  fidelity. 
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Table  3.  Activities,  methcxis,  and  tools  for  requirements  determination 


Activities  Determine  system  requirements 
Analyze  identified  needs 
Examine  different  user  viewpoints 
Perform  transaction  analysis,  create  scenarios 
Identify,  analyze  data  requirements 
Determine  functional  requirements 
Determine  non-functional  requirements 

Identify  alternatives,  wish  lists,  potential  enhancements  or  modifications 

Perform  trade-off  analyses 

benefit  for  added  cost 
benefit  for  extra  risk 

expected  lifetime,  evolveability  of  solutions 

uniqueness  of  solutions  vs.  common  needs  of  different  organizations 

Identify  problems,  issues,  risks 

Do  Planning 

Workload  characteristics  expected  for  the  future  system 

Developmental  constraints 

Schedule  and  resources  needed 

Allocation  of  people  and  resources  to  tasks  to  be  performed 

Methods  Prototyping 
Interviewing 
Specification 

data  flow,  object  oriented,  state  transition 

Templating 

n^  Chart 

Reviews  with  people,  e.g; 

discussion  groups 

Study  and  observation: 

current  environments,  existing  systems,  related  documents 
Market  the  idea 

Tools  Requirements  modeling  tools 

DFD,  Functional  Decomposition,  State  Drawings,  E-R  Diagrams,  Petri,  CORE 

Models 

Analytical,  Performance,  Simulation,  Cost 
Mission  Specific  Simulations 


3.3.3.3.2  Problems  and  Issues 

There  is  a  need  to  develop  improved  process  and  methods  to  help  identity  true 
requirements.  Problems  concerning  tools  limitations  were  also  identified.  Specifically,  cost 
models  are  usually  driven  by  "old"  data,  or  as  in  the  case  of  Ada  projects,  by  databases 
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which  simply  do  not  have  suHicient  information  or  enough  existing  Ada  projects  for 
baselining.  Simulation  models  are  limited  in  scope. 

3.3.3.3.3  Recommendations  and  Research  Areas 

The  group  recommends  that  research  be  supported  to  develop  improved  process  and 
methods,  and  to  increase  coupling  between  tools.  To  support  coupling  we  should  develop 
a  CASE  database  objects  standard.  The  integrated  tools  should  include  comprehensive 
multiple-view  support  with  consistency  checking,  view  generation,  and  support  for 
generation  of  test  cases.  Future  simulation  tools  should  support  multiple  levels  of 
abstraction  and  be  able  to  handle  changes  in  information  easily  (e.g.,  interactively). 

3.3.3.4  Requirements  Analysis 

Requirements  analysis  involves  analyse  of  expressed  requirements;  it  includes  related 
refinement,  elaboration,  and  correction.  (See  Table  4.) 

3.3.3.4.1  Discussion 

This  activity  focuses  on  improving  the  consistency,  completeness,  correctness,  and 
feasibility  of  the  existing  set  of  determined,  expressed  requirements  for  a  given  sj-stem. 
Consistency  checking  looks  for  requirements  which  are  in  contrast  or  direct  conflict  with 
others.  Completeness  checking  looks  for  omissions  in  the  expressed  requirements  that 
could  significantly  affect  developers’  ability  to  understand  or  build  what  is  wanted. 
Correctness  checldng  examines  whether  the  set  of  expressed  requirements,  if  followed,  will 
result  in  a  system  which  will  satisfy  the  user  and  long-term  needs  and  objectives. 
Feasibility  analysis  looks  at  whether  the  set  of  expressed  requirements  are  feasible  in 
terms  of  technology,  operation,  and  economy. 

In  addition,  this  activity  includes  evaluation  of  usefulness,  that  is,  to  what  degree  will  such 
a  developed  system  satisfy  the  current  and  future  needs  of  the  organization.  Significance, 
certainty,  and  interdependency  are  evaluated  to  help  plan  and  prioritize  work,  especially 
in  the  face  of  uncertainty  and  future  requirements  revision,  and  for  support  of  tradeoff 
analysis.  Testability  is  evaluated  both  because  it  is  needed  as  well  as  because  it  is  a 
measure  of  the  quality  of  expression  and  understandability  of  the  requirements. 

Finally,  this  activity  includes  identification  of  the  linkage  of  requirements  and  review  of 
their  traceability  in  order  to  support  thoroughness  and  consistency  of  future  revisions  of 
the  expressed  requirements,  to  support  testing  the  requirements  against  the  actual  system, 
and  to  support  maintenance  of  the  developed  system  when  needed  changes  or  repairs  are 
desired.  Several  methods  and  associated  tools  apply  to  these  activities.  Many,  but  not  all, 
are  listed  in  Table  4. 
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Table  4.  Activities,  methods,  and  took  for  requirements  analysis 


Activities  Con^ency  cliecidng 

Compteleness  chedcing 
Correctness  checking 

compare  specifications  to  major  system  objectives 

Analyze  feasibily 

phyacal,  financial,  cultural,  pofitical 

Review  testability 

Review  traceabifity  and  linkage 

Evaluate  significance,  certainty,  and  interdependencies 

Methods*  Prototyping 

Structured  Analysis  (including  modifications,  real-time  extensions),  e.g.: 
DeMarco,  JSD,  SADT,  Yourdon,  Ward-Mellor,  Hatley-Pirbai 

Object-Oriented  Analysis,  e.g.: 

001  AXES,  OORA 

Finite  State  Machines 

Other  specification  methods,  e.g: 

E-R  Models,  Operattonal,  Petri-Net,  PSU/PSA,  RIP,  SREM,  USE 

Quantitative  analysis,  mathematical  modeling 

View  Analysis 

Ranking,  weighting,  prioritizing 
Scenario  Building 
Simulations 

Tools*  Prototyping  Tools 

Requirements  Modeling  Tools.  e.g: 

Cadre,  IDS 

Analysis  Tools/Models 

consistency,  completeness,  performance 

Specification  tools,  e.g: 

Stalemate,  Dream,  PAISLey,  PCSL,  RTRL,  SSL 

CORE 


*  Note:  Most  of  these  methods  and  tools  are  associated  with  languages. 

For  more  thorough  listings  and  descriptions  of  methods  and  tools,  see  (a)  ’Software  Methodology  Catalog’  (U.S. 
Army  CECOM  Center  for  Software  Engineering  1989  0  Ft.  Monmouth,  NJ  07703-5000);  (b)  ’Mapping  the  Design 
Information  Representation  Terrain'  (Webster,  D.,  1988  D  IEEE  Computer,  Vol  21,  No.  12);  (c)  ’Requirements 
Engineering:  A  Systematic  Survey  of  the  Uterature'  (King,  K.N.,  1987  D  Software  Engineering  Research  Center, 
Georgia  Institute  of  Technology,  Atlanta,  GA  30332). 
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3.3.3.4.2  Problems  and  Issues 


Several  problems  with  tools  for  the  requirements  analysis  activity  were  identified.  First 
and  foremost,  there  are  no  multi-representational  tools  (ones  which  can  accomplish  all 
analytical  aspects)  currently  available.  Another  major  shortfall  identified  was  the  inability 
of  current  tools  to  tailor,  or  fine  tune,  their  representation.  Other  tools  suffered 
limitations  as  well  Consistency  tools  should  involve  balancing  various  models  to  ensure 
that  the  processes  and  data  identified  in  one  model  are  consistent  with  another,  e.g.,  Data 
Flow  Diagram  (DFD)  vs.  Entity-Relationship  Diagram  (ERD),  State  Transition  Diagram 
(STD)  vs.  DHD,  but  such  tools  are  limited. 

Problems  involving  the  extensibility  and  robustness  of  the  tools  were  noted  as  well. 
Current  completeness  tools  are  concerned  with  ensuring  data  identified  is  within  ranges 
and  values  at  identified  points,  but  completeness  involves  much  more  than  this.  Current 
performance  tools  are  concerned  with  evaluating  selection  by  performing  "rough  checks"; 
they  lack  detail  and  are  not  supported  by  models.  Such  rough  evaluations  are  insufficient 
for  yielding  the  analysis  results  needed  to  specify  systems  more  completely,  feasibly,  and 
to  support  satisfaction  of  the  "ilities". 

3.3.3.4.3  Recommendations  and  Research  Areas 

Recommendations  from  the  requirements  determination  section  apply  to  this  activity.  In 
addition,  further  research  into  knowledge-based  support  tools  is  recommended  for 
requirements  analysis.  Prototyping  tools  need  user  interface  definitions  which  are 
transparent  to  implementation  hardware.  More  robust  modeling  of  function  and 
performance  of  proposed  specifications  is  needed,  i.e.,  closer  to  actual  real-world 
situations.  Research  is  needed  to  learn  how  to  capture  non-  functional  requirements  to 
the  extent  that  the  impact  to  proposed  changes  in  a  non-functional  requirement  can  be 
predicted.  Finally,  support  for  development  of  tools  to  help  generate  and  capture 
operational  scenarios  is  recommended. 

3.3.3.5  Synthesis 

Synthesis  involves  formation  of  a  cohesive  specification  from  the  detailed  analyses;  it  also 
involves  integration  of  the  partitioned  analyses  that  have  occurred  due  to  problem 
complexity  and  breadth.  (See  Table  5.) 

3.3.3.5.1  Discussion 

The  activities  here  are  focused  on  synthesizing,  integrating,  revising,  and  polishing 
expressed  requirements  into  a  feasible,  consistent,  beneficial  set. 

Prototyping  for  synthesis  involves  constructing  or  using  prototypes  to  check  if  the  set  of 
requirements  can  be  synthesized  into  a  system.  Similarly,  simulations  should  mimic  the 
entire  system,  not  just  specific  parts,  to  examine  how  well  the  eventual  system  will  do  the 
job.  Sanity  checks  compare  sets  of  requirements  to  check  if  they  violate  one  another’s 
basic  assumptions.  Logical  models  are  used  to  reveal  any  potential  problems  with  the 
whole  set  of  requirements. 
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Table  5.  Activities,  methods,  and  tools  for  synthesis 


ActIvKIes  Resolve  conflicts 

Merge  models  and  viewpoints 
Integrate  concerns 

Integrate  non-functional  and  functional  requirements 
Collect  feedback  to  correct  objectives  and  specifications 

Methods  Prototyping 

Simulation 
Sanity  Check 
Logical  Modeling 

Tools  Requirements  Modeling  Tools 

Prototyping  Tools 


The  main  emphasis  of  the  tools  should  be  to  help  the  user  observe  the  requirements  at 
work  (i.e.,  in  action). 

3.3.3.5.2  Problems  and  Issues 

The  main  problems  center  on  tool  deficiencies.  Prototyping  is  not  rapid  enough.  There 
is  not  enough  support  for  import/export  between  tools  and/or  models,  both  internal  to  this 
activity,  and  between  this  and  other  major  activities.  In  addition,  there  is  often  a 
problematic  issue  of  what  to  do  when  a  user  wants  to  keep  the  prototype  as  a  part  of  the 
real  system  (not  throw  it  away  after  completion).  Most  prototypes  aren’t  built  to  be 
user-robust. 

3.3.3.5.3  Recommendations  and  Research  Areas 

Recommended  research  should  focus  on  synthesis  of  data  schemas,  and  rapid  prototyping 
via  application  domain  reuse.  More  robust  executable  specifications  are  needed  to 
examine  the  logic  and  function  of  proposed  behaviors  in  more  realistic,  dynamic  ways. 
Generally,  research  support  for  requirements  synthesis  tools  is  needed. 

3.3.3.6  Validation 

Validation  involves  ensuring  that  the  expressed  requirements  match  real  user  needs  and 
constraints.  (See  Table  6.) 
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Table  6.  Activities,  methods,  and  tools  for  validation 


Activities  Collect  stakeholders  critiques,  evaluations,  reviews,  and  analyses. 

Stakeholders  are: 
users 
customers 
developers 
QA  people 
V&V  people 

Methods  Walkthroughs 

Reviews 

Inspections 

Evaluations  of: 

Mock-ups 

Prototypes 

Simulations 

Testing: 

testbeds 
trial  use 

alpha,  beta  testing 

feedback  during  informal  development  tests  and  integration 

Tools  Executable  Specifications 

Prototyping  Tools 
Simulation  Models 
Scenario  Analysis 
Testbeds 
Theorem  Provers 


3.3.3.6.1  Discussion 

Validation  is  critical  to  the  requirements  process.  It  entails  examining  the  appropriateness 
of  expressed,  synthesized  requirements  to  judge  and  revise  the  system  mission  and 
objectives,  and  any  or  all  system  specifications. 

Validation  of  requirements  is  not  the  culmination  of  the  generic  requirements  process. 
Rather,  it  is  an  on-going  activity. 

Whereas  traditionally  communication  with  the  user  community  has  been  thought  to  be  a 
critical  factor  only  for  the  validation  of  requirements,  we  take  exception  to  this  view  on 
two  counts.  First,  we  believe  that  communication  with  the  user  community  is  a  critical 
factor  for  ah  the  generic  activities.  Second,  we  believe  that  validation  comes  not  just  from 
the  user  community,  but  from  all  the  stakeholders,  e.g.,  users,  customers,  developers,  QA 
and  V&V. 


Methods  emphasize  collecting  evaluations  and  experiencing  the  ramifications  of  expressed 
requirements  through  testing,  trial  use,  thought  experiments,  etc.  Support  of  breadth  of 
use  and  examination  is  encouraged.  Collection  and  assimilation  of  feedback  is  essential. 
Tools  that  support  this  activity  include  those  for  prototyping,  generation  of  executable 
specifications,  simulations,  scenarios  and  testbeds.  Proofs  of  correctness  are  a  desirable 
feature  for  validation  with  theorem  provers  as  a  potential  tool. 

3.3.3.6.2  Problems  and  Issues 

The  major  problems  with  the  tools  being  used  are  their  limited  applicability  (they  don’t 
scale  up  to  a  system-wide  version)  and  the  fact  that  many  (most)  of  the  requirements 
models  are  not  interoperable  with  the  validation  models.  This  relates  to  the  problem  of 
inadequate  import/export  capability  in  most  tools. 

3.3.3.6.3  Recommendations  and  Research  Areas 

Recommendations  for  research  include  the  following: 

•  Coupling  working  models  to  real-world  stimuli; 

•  Enabling  dynamic  analysis  through  animation  of  requirements  statements,  especially 
time  based  analysis; 

•  Greater  focus  on  long-term  research,  such  as  for  theorem  provers. 

3.3.37  Activities  Across  Ail  Phases 

Several  activities,  methods,  and  tools  were  identified  for  most  of  the  generic  activities  of 
the  requirements  process.  (See  Table  7.) 


3.3.3.7.1  Discussion 

Obviously,  a  commonly  identified  activity  across  all  activities  in  the  requirements  process 
is  creation  and  revision  of  some  type  of  dictionary  and/or  documentation  facility.  This 
activity  is  coupled  with  traceability  to  support  more  seamless  flow  between  requirements 
expression,  development,  and  revision  of  both  requirements  and  product.  Impact  analysis 
closely  relates  to  traceability,  as  does  configuration  management.  These  activities  are 
embraced  by  some  current  CASE  tools,  but  most  are  limited  in  their  applicability. 

The  identification  of  activity  commonality  can  be  deceiving.  We  cannot  emphasize 
strongly  enough  that  while  the  activity,  and  even  sometimes  the  method  and  tool 
identified  are  the  same,  the  focus  or  application  of  the  activity  is  different.  This  is  part 
of  the  reason  for  identifying  the  generic  activities  -  to  encourage  these  multiple  focuses. 
Prototyping,  for  example,  is  an  activity  of  trial  building  to  investigate  alternatives.  "What 
it  is"  that  is  being  investigated  varies,  depending  on  the  main  generic  activity.  Hence,  the 
use  and  purpose  of  prototyping  will  vary.  Similarly,  there  is  variation  depending  on  context 
for  recording  rationale;  creating  and  using  executable  specifications,  simulations,  and 
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Table  7.  Activities,  methods,  and  tools  applicable  to  several  generic  requirements  activities 

Activities  Creating  and/or  revising  documentation 

Creating/revising  dictionaries 
Recording  and  checking  rationale 
Traceability 
Impact  analysis 
Configuration  management 

Methods  Prototyping 

Interviewing 
Reviewing  documents 
Modeling 

Tools  Traceability  Tools/Oatabases 

Impact  Analysis  Tools 
Document  Production  Tools 
Data  Dictionaries 

Configuration  Management  Systems 


models;  interviewing;  and  acquiring  feedback.  The  fact  that  the  same,  or  closely  related, 
methods  and  tools  can  be  used  to  support  these  activities  is  a  great  advantage  and 
opportunity.  In  the  previous  discussions  of  problems  and  issues  we  have  indicated  that 
this  opportunity  is  not  being  sufficiently  seized  upon.  For  example,  limited  applicability 
was  a  commonly  cited  problem,  as  was  lack  of  tool  integration,  lack  of 
multi-representation,  and  lack  of  extensibility  and  robustness. 

3.3.3.7.2  Problems  and  Issues 

The  number  one  issue  with  regard  to  the  requirements  process  in  general  concerns 
primacy  of  requirements  and  needed  education.  Although  it  comes  as  no  surprise  to 
requirements  engineers,  the  centrality  or  primacy  of  requirements  needs  to  be  reinforced 
as  both  a  policy  and  a  practice  within  the  systems  development  life  cycle.  For  example, 
the  life  cycle  should  prohibit  a  systems  developer  from  changing  a  few  lines  of  code  and 
updating  the  systems  design  without  also  updating  the  requirements  data  base  or  certifying 
that  the  current  design  or  code  change  does  not  change  the  requirements.  The  way  to 
maintain  a  system  is  via  the  requirements  -  propose  changes  in  the  requirements  data  base 
(see  para  5.3.7.3,  recommendation  B.),  then  review  them  (impact  analysis,  engineering 
review,  management  review),  and  finally  forward  the  approved  changes  into  design  and 
implementation. 
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Other  specific  problems  and  issues  identified  as  applicable  to  all  the  six  generic 
requirements  engineering  subprocesses  -  context  analysis,  objective  analysis,  requirements 
determination,  requirements  analysis,  synthesis,  validation  -  were  as  follows: 

•  How  do  you  identify  the  entry  and  exit  criteria  for  each  activity,  e.g.,  how  do  you 
know  when  you’re  done  defining  a  requirement; 

•  Robust  methods  and  tools  for  trade-off  analysis  is  lacking. 

•  Insufficient  consistency  and  completeness  checking  at  multiple  levels  of  abstraction; 

•  Lack  of  integration  of  requirements  and  development  processes; 

•  Lack  of  clear  delineation  between  prototyping  and  mock-up  impairs  selection  of 
different  approaches  to  system  validation  and  requirements  determination; 

•  Lack  of  traceability  and  requirements  linkage;  e.g.,  need  to  identify  a  model  to 
depict  the  relationships  and  interactions  among  a  set  of  requirements; 

•  Insufficient  ability  to  handle  rapid  change  and  its  impact  on  requirements; 

•  Impact  analysis  tools  are  limited  in  capability; 

•  Most  data  dictionaries  are  not  object  oriented; 

•  Configuration  management  tools  are  limited,  control  does  not  extend  to  manage 
changes  of  each  individual  requirement. 

3.3.3.7.3  Recommendations  and  Research  Areas 

Seventeen  research  topics  were  identified.  Each  is  listed  below  along  with  explanatory 
text. 

1.  Groupware  to  formulate  and  clarify  operation  concepts  and  critical  success  factors. 
A  number  of  consensus  oriented,  decision-support  oriented,  and  knowledge-based 
approaches  towards  facilitating  group  efforts  are  now  surfacing.  The  application  of 
these  techniques  to  the  early  activities  of  the  requirements  engineering  domain 
should  be  most  beneficial. 

2.  A  life  cycle  requirements  database  to  capture  and  manage  attributes  of  individual 
requirements  and  provide  traceability.  Given  that 

•  The  requirements  data  base  is  the  central  repository  of  the  system 
requirements, 

•  All  changes  to  requirements  need  to  use  this  data  base  to  perform  impact 
analysis  of  candidate  changes,  and 
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•  This  data  base  must  be  kept  current  to  reflect  all  approved  changes,  there  is 
then  a  premium  on  traceability  and  linkage  of  requirements  as  well  as  the 
management  of  requirements  attributes,  such  as  level  of  importance,  degree 
of  certainty  (in  the  statement),  potential  for  change,  expected  requirements 
life  span,  etc.  Tools  and  methods  are  crucial  to  facilitating,  evaluating  and 
possibly  automating  these  requirements  data  base  maintenance  tasks. 

This  recommendation  can  be  made  even  stronger.  To  support  tracing 
requirements  to  designs  to  code  to  tests  to  documentation,  etc.,  a 
requirements  database  must  be  integrated  with  a  database  which  spans  all 
development  and  usage  activities,  not  merely  activities  which  cover  the 
requirements  aspects. 

3.  Identify  a  requirements  model(s)  to  describe  the  interaction  among  requirements 
to  provide  understanding  and  synthesis  support.  Extensive  requirements 
specifications  are  difficult  to  understand  holistically!  In  addition  to  tracing  and 
linkage,  as  well  as  proximity  analysis  methods  (such  as  incidence,  precedence, 
reachability  and  clustering  matrices)  there  needs  to  be  a  better  understanding  of  the 
higher  meaning  of  several  requirements  interacting  together.  Such  synthesis  of 
requirements  can  be  supported  by  requirements  models. 

4.  Mechanism  for  trade-off  analysis.  Tools  and  techniques  are  needed  to  capture, 
organize,  and  help  evaluate  the  many  trade-offs  that  occur  in  requirements 
development.  Intelligent  impact  analysis  is  an  example. 

5.  More  seamless  integration  between  tools,  and  between  requirements 
representations,  to  support  propagation  of  change.  As  the  requirements  change  - 
either  as  direct  changes  to  an  underlying  data  base  or  as  changes  in  generated 
textual  or  diagrammatic  derivatives  -  all  representations  of  the  requirements  must 
be  updated  to  reflect  the  change.  Research  into  better  linkage  between 
representations  is  needed.  Correspondingly,  there  is  need  for  automated  tools  that 
link  such  methods  as  data  flow,  object  oriented,  state  diagrams,  text,  etc.,  so  changes 
in  any  such  representation  are  reflected  in  all  representations.  Other  related  tools 
include  those  for  automatically  maintained  consistency,  configuration  management, 
and  automated  documentation  generation. 

6.  Methods  for  self-consistent,  rapid  modification  of  large  systems.  When  emergency 
changes  are  made  to  mission-critical  software,  the  requirements  are  often  not 
updated  (synchronized).  Better  methods  and  automated  support  for  maintaining 
requirements  data  base  consistency  are  needed  to  correct  this  problem. 

7.  Reverse  engineering  methods  to  derive  requirements  from  existing  systems.  A 
number  of  existing  systems  are  not  accurately  reflected  in  their  requirements.  This 
greatly  limits  the  use  and  re-use  of  those  systems.  Failing  to  maintain 
synchronization  between  the  requirements  statement  and  the  implemented  system 
as  the  system  evolves,  there  is  a  need  to  use  reverse  engineering  to  (re-)synchronize 
them. 
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8.  Process  modeling  tool  for  active  guidance;  and  integration  of  major  activities. 
Managers  and  engineers  like  neatly  formed  boxes  with  clean  arrows  leading  between 
them.  Unfortunately,  the  real  world  of  software  requirements  is  not  that  well 
ordered.  There  is  a  need  to  determine  criteria  for  leaving  a  major  activity, 
returning  to  one,  and  transversing  among  the  different  activities  of  the  requirements 
engineering  process.  Data  on  project  statistics  that  correlates  historical  decisions 
with  results  would  be  of  value  here. 

9.  Mechanisms  and  metrics  for  aiding  selection  of  methodologies.  How  do  we  choose 
which  methodology  (object  oriented,  data  flow,  state-transition,  etc.)  is  best  for  any 
given  requirements  life  cycle  task?  Collection  and  publication  of  data  on  project 
statistics  would  support  this. 

10.  Hierarchical,  multi-level  Process  Definition  Language  (HPDL)  to  facilitate 
expansion  of  requirements  including  localization,  decomposition  and  information 
hiding.  This  tool  would  provide  a  method  for  several  requirements  engineers 
(different  stakeholders,  each  with  different  levels  of  responsibility  and  domains  of 
expertise)  to  identify  and  add  detail  in  an  orderly  way  in  formulating  a  requirement. 
Information  hiding  and  multiple  levels  of  detail  are  beneficial  characteristics  for 
requirements  browsing  or  other  usage  of  requirements  expression.  For  example,  an 
initial  HPDL  statement  might  be: 

Develop  a  payroll  accounting  system 
Pay  hourly  employee 
Pay  weekly  employees 

But  "outliner"  capabilities  may  enable  other  detail  to  be  present  or  be  added,  e.g.: 

Develop  a  payroll  accounting  system 
Pay  hourly  employees 

{Determine  regular  pay  {  -  decomposition  } 

(Sum  up  regular  hours  worked  [  -  still  further  refined  by  an  accountant  ] 

Multiply  by  regular  pay  rate 
Add  in  bonuses.) 

Determine  over-time  pay 
Calculate  Deductions.} 

Pay  weekly  employees. 


11.  Mechanisms  for  expressing  ambiguity.  There  needs  to  be  a  method  to  purposely 
express  ambiguity  (such  as  response  must  be  fast)  as  a  temporary  place  holder.  A 
requirements  management  system  would  then  prompt  a  query,  when  it  finally  needs 
clarification,  such  as:  "What  do  you  mean  by  ’fast’?  Please  provide  parameters." 

12.  Rigorous  approach  to  consistency  and  completeness  checking  at  different  levels. 
Although  rigorous  mathematical  techniques  exist  for  consistency  and  completeness 
checking  at  the  lowest  level  of  requirements  detail,  e.g.,  data  item/process, 
techniques  do  not  exist  at  any  aggregate  levels.  In  general,  there  needs  to  be 
multiple  levels  of  formalism. 
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13.  Quantification  of  factors  in  needs  identification  and  analysis.  A  number  of 
requirements  attributes  need  to  be  quantified;  methods  and  metrics  are  needed. 

14.  "Ilities"-driven  requirements  engineering  methods.  "Ilities",  expressed  in 
non-functional  requirements,  are  either  (1)  those  which  do  not  directly  trace  to 
basic  operational  concepts  but  rather  to  external  constraints,  or  (2)  those 
requirements  which,  unlike  functional  requirements,  we  have  not  yet  learned  to 
express  formally.  A  number  of  "ilities",  chief  among  them  maintainability  (or 
flexibility  to  change),  need  to  be  built-in  to  requirements  as  special  items  to  be 
considered  throughout  the  requirements  engineering  process. 

15.  Template  and  tools  for  identifying  and  describing  "ilities".  First  a  template  to 
identify  the  non-functional  requirements  or  "ilities"  (see  item  #14  above)  in  order 
to  keep  them  from  falling  through  the  cracks  and  then  tools  and/or  languages  to 
evaluate  and  express  these  non-functional  requirements  are  vital  to  this  ever 
important  portion  of  the  requirements  data  base. 

16.  Research  into  the  impact  of  parallel  processing  on  the  requirements  process. 
Determine  what  impact,  if  any,  parallel  processing  capabilities  in  the  target 
hardware  has  on  the  requirements  engineering  effort. 

17.  Develop  system  mock-up  approaches  and  tools  to  aid  requirements  determination 
and  system  validation.  Mock-ups  (not  to  be  confused  with  prototypes)  have  great 
utility  in  requirements  determination  and  system  validation.  This  technology  needs 
to  be  exploited  via  better  understanding  and  better  tools. 

3.3.4  Requirements  Languages 

Requirements  engineering  languages  are  mechanisms  to  express  and  control  requirements 
information.  A  requirements  engineering  language  can  be  proposed  in  two  basic  forms: 

•  A  syntax  for  a  specific  language  notation,  or 

•  A  schema  for  incorporating  several  language  notations. 

The  approach  taken  by  the  language  subgroup  was  to  identify  problems  and  issues  with 
current  requirements  specification  languages,  develop  a  set  of  objectives,  and  make 
recommendations  for  developing  an  encompassing  language  schema  to  incorporate  the 
strengths  of  the  many  specific  requirements  language  notations.  The  group’s  activity  was 
focused  by  constructing  a  set  of  tables  which  related  the  objectives  to  both  present  day 
languages  and  the  sbc  subprocesscs  in  the  requirements  definition  process.  In  order  to 
create  these  tables  the  group  progressed  through  an  actual  requirements  definition 
process.  Table  8  reflects  a  summary  of  the  tables  created  during  the  group  session. 

3.3.4.1  Requirements  Language  Problems  and  Issues 

The  generic  problems  of  system  requirements  are  inherently  due,  in  large  degree,  to  the 
difficulty  in  specifying  these  requirements  in  a  formal  language.  English  is  much  too 


52 


ambiguous  and  context  dependent  to  be  used  for  any  but  the  most  mundane  requirements. 
Design  languages  and  programming  languages  available  today  are  too  limited  to  express 
the  range  of  information  types  and  relationships  needed  to  fully  define  and  document 
system  requirements.  The  discovery  of  system  failures  due  to  errors  in  requirements  is  a 
continuing  nightmare. 

Current  problems  with  requirements  specification  languages  include  the  following: 

•  Currently  used  languages  fail  to  capture  requirements  information  effectively  to 
support  system  evolution. 

•  Non-functional  requirements  cannot  be  adequately  specified. 

•  The  synchronization  problem  -  Because  requirements  specifications  are  separate 
from  the  systems  they  represent,  there  is  no  automatic  way  to  ensure  that  changes 
to  systems  are  reflected  in  the  requirements,  or  vice  versa. 

•  Current  languages  are  not  expressive  enough  to  represent  diverse  viewpoints. 

•  There  are  too  many  gaps  in  knowledge  about  requirements  engineering.  This  leads 
to  gaps  in  the  formalisms  that  can  represent  system  requirements.  Functionally, 
requirements  languages  are  discontinuous  and  incomplete  across  the  spectrum  from 
concept  specification  to  executable  code  specification. 

•  Too  many  facts  have  to  be  known  before  any  requirements  specification  language 
can  be  used. 

3.3.4.2  Requirements  Language  Objectives 

A  comprehensive  and  integrated  technology  is  needed  for  use  in  defining  and 
automatically  developing  software  systems.  These  needs  point  to  a  wide-spectrum 
requirements  engineering  language.  Such  a  language  should  be  usable  to  both  define  a 
system  and  also  support  its  development.  Specifically,  such  a  language  should  include  the 
ability  to: 

•  Capture  real-world  definitions  -  These  include  the  definition  of  functions  and 
objects  in  an  object-oriented  environment,  and  the  mechanisms  to  hide  information 
based  on  different  views. 

•  Be  inherently  reliable  --  Implementation-specific  results  are  traceable  to 
requirements  objects  and  changes  in  objects,  inconsistency  and  logical 
incompleteness  are  not  allowed  from  the  largest  to  the  smallest  system  details  (e.g., 
data  flow,  priority,  and  timing  errors  are  eliminated). 

•  Maximize  flexibility  -  Requirements  can  be  specified  independent  of  platform;  can 
be  used  in  various  modes  (e.g.,  prototyping,  production,  documentation);  may  exist 
in  multiple  forms  or  syntaxes  but  have  a  single  semantic  meaning;  are  generally 


53 


declarative  and  non-procedural;  are  portable,  based  on  an  open  architecture, 
modular,  and  can  represent  various  levels  of  abstraction. 

•  Maximize  the  opportunity  for  parallelism  -  Dependent,  independent,  and 
decision-making  patterns  are  made  explicit  attributes  of  requirements.  Finding  out 
about  parallelism  issues  would  not  have  to  wait  until  implementation. 

•  Maximize  automation  -  Automatic  generation  of  executable  and  non-executable 
forms  of  the  system  are  supported;  multiple  forms  of  the  language  can  be 
generated;  multiple  forms  of  documentation  can  be  generated  (e.g.,  2167A 
documents,  FEPS  38,  7935);  and  automatic  analysis  for  adherence  to  control 
structures  rules  is  supported. 

•  Maximize  reusability  --  The  language  supports  parameterized  user  extensions. 
Reusability  would  not  have  to  wait  until  after  development. 

•  Maximize  productivity  -  The  combination  of  the  above  objectives  contributes  to 
orders  of  magnitude  of  productivity  improvements;  e.g.,  maintenance  is  minimized 
due  to  elimination  of  errors  in  requirements  specification  and  the  system  can  be 
made  visible  in  a  variety  of  automatically  generated  forms  for  analysis  from 
orthogonal  viewpoints. 

3.3.4.3  Language  Table 

An  analysis  of  the  importance  of  specific  existing  requirements  languages  against  the 
objectives  of  an  ideal  requirements  language  is  shown  in  Table  8,  Part  A.  Part  B  of 
Table  8  shows  the  impact  of  language-related  objectives  on  the  six  subprocesses  of  the 
requirements  definition  process.  The  uncertainties  in  these  estimates  are  reflected  in  the 
group’s  judgement  that  the  actual  usefulness  of  the  languages,  based  on  real  life 
experiences,  seemed  closer  than  a  comparison  of  the  averages  suggest. 

3.3.4.4  Requirements  Language  Recommendations 

The  analysis  of  requirements  for  a  wide-spectrum  requirements  specification  language  led 
to  the  following  recommendations: 

•  The  language  should  incorporate  both  non-procedural  and  procedural  constructs. 
It  should  require  the  user  to  enter  a  minimum  of  control  and  data  management 
information. 

•  It  should  provide  multiple  views  of  the  system  based  on  environmental  contexts,  i.e., 
graphical  for  conceptual  views,  textual  for  analysis,  etc.,  but  the  semantic  meaning 
should  be  constant  for  all  views. 

•  The  language  should  be  executable  for  animation,  simulation,  and  prototyping 
purposes. 
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Table  8.  Ideal  requirements  language  objectives 


PART  A 


Current  Requirements  Languages 


Logic  Based 


Functional 


Ada 


Object  Oriented  (Smalltalk,  C++,  Simula) 


Structured  Analysis  (SADT,  SA/RT,  etc.) 


VDM 


001  AXES 


4GL 


PROTO 


LANGUAGE-RELATED  OBJECTIVES 


Average 


2.5 


2. 


3.0 


3.5 


2.7 


PARTS 

UNGUAGE-RELATED  OBJECTIVES 

Average 

Requirements  Sub-Processes 

1 

2 

3 

B 

5 

6 

Context  Analysis 

5 

1 

5 

5 

2 

5 

3.8 

Objective  Analysis 

5 

1 

5 

5 

2 

5 

3.8 

Requirements  Definition 

3  . 

2 

5 

3 

4 

5 

3.7 

Requirements  Analysis 

3 

2 

5 

3 

5 

5 

3.8 

Synthesis 

2 

5 

5 

2 

5 

5 

4.0 

Validation 

2 

5 

5 

2 

5 

5 

4.0 

WelQhtino  Factors 

1  =  minimum  effect  5  =  maximum  effect 
Language-Related  Objectives  Key 

1  =  Captures  Real-World  Definitions  4  =  Maximizes  Opportunity  for  Parallelism 

2  =  Concentrates  on  Reliability  5  =  Maximizes  Automation 

3  =  Maximizes  Flexibility  6  =  Maximizes  Reusability 

Average  (1-6)  =  Maximizes  Overall  Productivity 
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•  It  should  minimally  provide  the  mechanisms  for  defining  abstract  high  level 
concepts,  intermediate  architectures,  logical  and  physical  design  information,  and 
environmental  constraints  in  both  canonical  and  orthogonal  forms. 

Several  recommendations  surfaced  as  prescient  and  necessary  for  implementation  of  many 
of  the  other  recommendations: 

•  Develop  knowledge  representations  for  requirements  information. 

•  Solve  the  problem  of  defining  the  so-called  ’non-functional’  requirements. 

•  Map  project  management  and  control  structures  to  system  views  for  automatic 
determination  of  static  and  dynamic  resource  allocation. 

•  Develop  a  wide-spectrum  requirements  engineering  language  that  meets  the 
objectives  defined  in  this  section. 

3.3.5  Glossary 

001  AXES  -  Object-oriented  requirements  language  and  methodolo^  based  upon  a 
concept  of  control 

Behavioral  Prototype  •  A  prototype  used  to  model  what  the  system  is  supposed  to  do. 
It  is  black-box,  and  exhibits  responses  to  stimuli.  It  is  used  for  concept  e.xploration  and 
validation. 

CORE  -  Controlled  Requirements  Engineering. 

Delphi  Method  -  In  a  Delphi  method  several  people  prepare  estimates  independently 
and  are  then  told  how  their  estimates  compare  to  those  of  the  others.  Next,  they  are 
allowed  to  alter  their  estimates.  This  leads  to  an  iterative  technique  in  which  many  of  the 
estimates  finally  converge  to  a  narrower  range  from  which  a  single  value  may  be  chosen. 

DREAM  -  Design  Realization,  Evaluation,  and  Modeling  system. 

E-R  Models  -  Entity  Relationship  models. 

Functional  Requirements  -  Requirements  that  express  behaviors  expected  of  a  system, 
i.e.,  what  the  system  should  do. 

JSD  -  Jackson  Structured  Design. 

Meta-system  -  The  set  of  systems  that  together  support  a  given  domain. 

Mock-up  -  Material  simulation  of  a  system  component  used  to  help  visualize  that 
component’s  functionality. 
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Non-fimctioiial  Requirements  -  Requirements  that  express  constraints,  attributes,  or 
qualities  that  ^tems  must  possess  or  exhibit 

OORA  >  Object-Oriented  Requirements  Analysis. 

PAISLcj  -  Process-oriented,  Applicative,  and  Interpretable  Specification  language. 

PCSL  -  Process  Control  Software  Specification  language 

Petri  Nets  -  A  directed  graph  representation  language  supporting  parallel  design. 

Prototype  -  An  initial  implementation  of  a  component  or  a  system.  It  is  generally 
deficient  in  one  or  more  areas  (e.g.,  performance,  functionali^,  or  robustness),  but  is  able 
to  demonstrate  some  features  of  interest  Prototypes  are  useful  for  investigating  system 
behavior  and  structure.  See  also  Behavioral  Prototype  and  Structural  Prototype. 

PSL/PSA  -  Problem  Statement  Language  /  Problem  Statement  Analyzer. 

Requirements  Centered  Development  Life  Cycle  Model  -  The  requirements  process 
serves  as  the  command  and  control  center  for  system  evolution.  It  steers  other  activities 
(e.g.,  prototyping,  design,  testing,  validation),  but  requires  information  input  from  those 
activities  to  do  so. 

Reverse  Engineering  -  Getting  the  documentation  for  existing  systems  "in  sync"  with  the 
system’s  actual  implementation.  This  especially  includes  the  requirements  documentation. 

RLP  -  Requirements  Language  Processor. 

ROI  -  Return  on  investment 

RTRL  -  Real-Time  Requirements  Language. 

SADT  -  Structured  Analysis  and  Design  Technique 

Scenario  -  A  sequence  of  events  which  occur  in  the  system/environment  setting,  or  only 
within  the  system  itself.  A  frequent  use  of  scenarios  is  to  depict  the  reaction  of  the 
system  (also  an  event)  to  one  or  more  prior  events,  i.e.,  stimulus/response  group(s). 

Scheme  -  A  way  of  performing  a  set  of  activities. 

Simulation  -  An  executable  model  or  mock-up  of  the  system,  or  a  significant  part  of  it, 
which  exhibits  behavior  or  characteristics  that  aid  analysis  of  issues.  The  inner  mechanism 
of  the  simulation  may  have  little  in  common  with  the  final  system  solution. 

SREM  -  Software  Requirements  Engineering  Methodology. 

SSL  -  System  Specification  Language. 
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Stakeholders  -  Persons  or  organizations,  by  category,  who  are  participants  in  the  process 
and  who  have  particular  needs,  concerns,  or  responsibilities  related  to  system  deOnition, 
development,  use,  or  acquisition. 

Structural  Prototype  -  A  prototype  used  to  model  how  the  system  will  accomplish  its 
black-box  behavior.  Thus,  a  structural  prototype  is  a  dear-box  model.  It  is  used  to 
determine  feasibOity,  explore  design  alternatives,  and  estimate  implementation  and 
execution  costs. 

USE  -  User  Software  Engineering  Methodology. 

Verification  and  Validation  (V&V)  -  Analysis  to  judge  whether  requirements  artifacts 
adequatety  express  user  needs  and  meet  other  quality  attributes;  to  judge  whether  the 
actual  needs  appear  to  have  been  perceived  sufficiently;  and/or  to  judge  and  evaluate  the 
tystem  in  terms  of  progress  toward  satisfying  the  requirements. 
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3.4  Working  Group  3: 

Rapid  Prototyping  and  Knowledge-Based  Techniques 

Edited  by:  Dr.  Winston  W.  Royce,  Working  Group  Chair,  with  Mr.  Robert  M.  Poston. 

3.4.1  General  Information 


3.4.1 .1  Working  Group  Participants 


NAME 

EMPLOYER 

COUNTRY 

Bagley,  David 

CECOM  Center  for  Software  Engineering 

USA 

Casey,  Philip 

US  Army  Training  &  Doctrine  Command 

USA 

Conrad,  Thomas  P. 

Naval  Underwater  System  Center 

USA 

Greene,  Cordell 

Kestrel  Institute 

USA 

Harris,  David  R. 

Sanders  Associates,  Inc. 

USA 

Huskins,  James 

Naval  Post  Graduate  School 

USA 

Johnson,  W.  Lewis 

University  of  Southern  California 

USA 

Little,  Reed 

Camegie-Mellon  University  (SEI) 

USA 

Morel,  Martin 

Le  Groupe  CGI 

Canada 

Poston,  Robert  M. 

Programming  Environments  Inc. 

USA 

Royce,  Winston  W. 

SoftwareFirst 

USA 

Sobolewski,  Victor  C. 

Australian  Embassy 

Australia 

Stachowitz,  Rolf 

Lockheed 
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Watgen,  David 

Advanced  Technology  Inc. 

USA 

3.4.1 .2  Roadmap:  A  Guide  to  Working  Group  3  Activities 


This  report  on  the  activities  of  Working  Group  3  is  divided  into  four  parts.  The 
introduction  defines  the  problem  domain  of  the  two  subtopics  and  the  working  group’s 
approach.  This  is  followed  by  an  issues  section,  then  recommendations,  and  finally  a 
glossary.  The  issues  and  recommendations  sections  treat  the  two  subtopics  separately. 
Each  issues  subsection  begins  by  posing  a  series  of  questions  that  the  group  deemed 
central  to  the  subtopic.  The  rest  of  the  subsection  analyzes  each  of  the  questions  in  turn. 
The  recommendations  are  divided  into  recommendations  for  management  and  policy, 
development,  and  research. 
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3.4,2 


Introduction 


3.4.2. 1  Definitions  and  Problem  Domain 

The  task  of  Working  Group  3  was  to  analyze  two  specific  aspects  of  requirements 
engineering:  Knowledge-Based  Approaches  (KBA)  and  rapid  prototyping. 

Knowledge  bases  are  repositories  of  formalized  knowledge  about  a  domain  or  area  of 
expertise.  A  knowledge-based  approach  is  a  technique  that  actively  employs  knowledge 
bases  and  knowledge-based  tools.  KBAs  may  be  used  to  facilitate  and  enhance 
requirements  engineering. 

A  prototype  is  an  executable  model  of  a  proposed  system.  It  may  include  only  a  partial 
functionality  of  the  final  system.  It  is  generally  not  optimized  for  performance  and  may 
be  written  in  a  fourth-generation  language  (4GL).  Uses  of  prototypes  include 
demonstration  of  the  user  interface  of  the  system  and  testing  of  various  aspects  of  the 
future  system.  Rapid  prototyping  refers  to  the  incremental  process  of  building  prototypes 
in  a  relatively  short  amount  of  time. 

Requirements  engineering  is  currently  a  complex,  error-prone,  manual  task.  Often  it  is 
difficult  to  stipulate  the  requirements  and  specifications  for  a  system  at  the  beginning  of 
a  project.  Yet,  a  thorough  requirements  engineering  process  can  greatly  improve  product 
quality  as  well  as  increase  the  productivity  of  the  design  and  test  phases  and  reduce  the 
amount  of  time  spent  on  maintenance  of  the  system.  Knowledge-based  approaches  and 
rapid  prototyping  can  be  used  to  strengthen  and  improve  requirements  engineering.  The 
task  of  Working  Group  3  was  to  explore  the  issues  involved  in  employing  rapid 
prototyping  and  knowledge-based  approaches  for  requirements  engineering  and  to  develop 
a  set  of  recommendations  aimed  at  incorporating  these  techniques  into  the  software 
development  process. 

3.4.2.2  Working  Group  Approach 

Working  Group  3  met  in  three  sessions.  Unlike  the  other  working  groups,  it  did  not 
break  up  into  individual  subgroups.  During  the  first  session,  the  group  considered  a  set 
of  ten  questions  (five  knowledge  base  questions  and  five  rapid  prototyping  questions) 
which  had  been  prepared  in  advance  by  Chairperson  Dr.  Winston  Royce.  Members  of 
the  group  added  their  own  questions  to  this  list  (for  a  total  of  twenty-one  questions)  and 
then  voted  to  determine  which  questions  were  most  urgent.  Eleven  of  these  were 
rejected  as  being  of  a  lower  priority,  and  the  remaining  ten  questions  were  combined  into 
a  set  of  seven  questions  (four  knowledge  base  questions  and  three  rapid  prototyping 
questions).  For  each  question,  one  person  was  assigned  to  lead  the  discussion  of  the 
question  and  a  second  person  was  assigned  to  record  the  responses  to  the  question  (the 
scribe).  The  remainder  of  the  first  session  was  a  brainstorming  session  in  which  answers 
to  and  pertinent  issues  of  the  seven  selected  questions  were  suggested  and  recorded.  If 
the  proposed  ideas  were  in  conflict,  no  attempt  was  made  to  reconcile  the  conflicts  at  this 
time. 
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The  second  session  focussed  on  the  seven  questions  for  a  second  time,  with  question 
leaders  and  scribes  in  reversed  roles.  The  issues  and  answers  were  elaborated  on  and 
conflicting  views  were  resolved.  Based  on  these  issues  and  answers,  a  set  of 
recommendations  was  developed  and  recorded. 

The  third  session  cleaned  up  any  final  concerns  and  made  some  minor  changes  to  the 
issues,  answers  and  recommendations.  Question  leaders  and  scribes  then  met  to  draw  up 
the  final  issues  and  recommendations  for  each  question  in  preparation  for  the  16 
November  presentation. 

3.4.3  Issues 

The  following  sections  address  the  issues  that  arose  while  analyzing  knowledge-based 
techniques  and  rapid  prototyping. 

3.4.3.1  Knowledge-Based  Techniques 

The  following  questions  pertaining  to  knowledge-based  approaches  to  requirements 
engineering  were  examined: 

•  Are  knowledge-based  approaches  to  requirements  engineering  useful  for  real 
systems?  What  kinds  of  requirements  engineering  problems  are  best  solved  by 
KB  As? 

•  What  are  the  special  risks  of  using  KBAs  for  requirements  engineering?  What  are 
the  benefits  of  using  KBAs  for  requirements  engineering? 

•  What  changes  are  needed  in  the  software  development  process  -  and  what  features 
are  needed  in  our  models  of  the  software  development  process  -  to  exploit 
knowledge-based  approaches? 

•  What  are  the  existing  knowledge-based  systems  and  tools? 

The  following  sections  grapple  with  each  of  these  questions  in  turn. 

3.4.3.1 .1  The  Use  of  KBAs  and  Their  Application  To  Real  Systems 

In  determining  the  usefulness  of  KBAs  for  requirements  engineering,  the  following 
observations  were  made: 

•  Size  of  application.  The  feasibility  of  KBAs  for  requirements  engineering  has  been 
established  for  applications  ranging  in  size  from  1000  to  30,000  requirements. 
Extensions  to  higher  ranges  remain  uncertain. 

•  Availability  of  expertise  to  establish  knowledge  base.  The  availability  of  expertise 
to  establish  the  required  knowledge  base  varies  significantly  with  the  application 
domain.  Obviously,  the  more  available  the  knowledge  is  (the  human  experts  used 
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to  build  the  knowledge  base),  the  more  potentially  useful  a  KBA  approach  will  be 
to  the  system. 

•  Maturity  of  KBA  tools.  Although  several  automated  tools  are  available  to  support 
KBAs,  there  have  been  relatively  few  experiences  involving  large  applications. 
Consequently,  there  is  some  question  of  tool  robustness. 

•  Skill  base  for  using  KBAs,  In  contrast  with  the  expertise  required  for  building 
knowledge  bases,  it  is  unknown  whether  there  will  be  need  for  long  learning  periods 
prior  to  effective  use  of  KBA  tools.  It  seems  to  depend  on  the  particular  tool. 

•  Quality  of  KBA-generated  requirements.  There  is  a  definite  need  to  develop  data 
on  the  quality  of  KBA-generated  requirements.  It  has  yet  to  be  established  whether 
or  not  KBA-generated  requirements  are  of  a  higher  quality  than  "normal" 
requirements.  The  lack  of  such  data  is  an  obstacle  to  the  extended  use  of  KBA’s. 

•  Quantification  of  costs/benefits.  There  is  a  definite  need  to  develop  data  on  costs 
and  benefits  deriving  from  the  use  of  KBAs  for  requirements  engineering.  The  lack 
of  such  data  is  a  serious  obstacle  to  the  expanded  use  of  KBAs  in  the  near  term. 

•  Functional  vs.  non-functional  requirements.  While  there  was  intuitive  agreement 
that  KBAs  are  potentially  useful  for  both  functional  and  non-functional 
requirements  engineering,  concern  was  expressed  about  a  more  fundamental 
problem.  There  are  no  (known)  KBAs  that  address  non-functional  requirements, 
and  there  is  a  serious  need  for  research  in  the  realm  of  knowledge  acquisition 
regarding  requirements. 

•  Context  of  the  knowledge.  The  context  must  be  sufficiently  bounded  for  KBAs  to 
be  useful. 

3.4.3.1.2  Risks  and  Benefits  Of  Using  KBAs  For  Requirements  Engineering 

The  following  were  identified  as  special  risks  of  using  KBAs  for  requirements  engineering: 

•  High  cost  per  user  ratio.  If  an  organization  is  going  to  build  a  knowledge-based 
system,  substantial  resources  will  be  invested  in  the  requirements  analysis  phase. 
The  resulting  knowledge  base  is  typically  narrow  and  application  dependent,  with 
a  low  probability  for  reusability. 

•  Lack  of  skill  base.  There  is  a  lack  of  a  skill  base  in  doing  requirements  engineering 
and  creating  knowledge-based  systems.  This  impacts  system  quality  and  cost. 

•  Lack  of  suitable  methodology.  Knowledge-based  systems  are  new  and  very  complex. 
Without  a  formal  methodology,  the  system  may  be  misused. 

•  Lack  of  productivity  metrics.  There  is  a  lack  of  standardized,  accepted  productivity 
metrics  which  would  demonstrate  why  it  is  better  to  use  a  KBA  over  another 
approach. 
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•  Overdependence.  Systems  are  not  envisioned  to  replace  human  creativity  and 
critical  thinking. 

•  Liability.  There  are  potential  legal  liability  issues  as  to  who  would  be  accountable 
for  any  errors  in  the  knowledge  base  and  the  harm  they  may  cause. 

The  following  were  identified  as  special  benefits  of  using  KBAs  for  requirements 

engineering: 

•  Reuse.  The  use  of  a  knowledge  base  would  provide  corporate  memory  as  well  as 
project  memory.  Better  tracking  of  intra-project  dependencies  are  facilitated  by 
knowledge-bases.  Later,  products  that  reuse  the  knowledge  bases  will  require  fewer 
up-front  cost  and  time  investments.  Existing  knowledge  bases  could  also  be 
marketable. 

•  Better  Management  of  Changing  Requirements  throughout  the  software  life  cycle. 
Knowledge-based  approaches  provide  the  means  to  improve  the  integration  of 
requirements  with  other  life  cycle  phases.  They  support  "live"  requirements,  ie. 
requirements  that  are  continually  being  changed  and  upgraded  throughout  the 
software  life  cycle.  Knowledge-based  approaches  would  also  provide  the  ability  to 
compute  the  impact  of  changing  requirements  on  the  system  and  to  generate 
documentation  from  requirements. 

•  Improved  accuracy.  When  used  properly,  it  was  felt  that  knowledge-based 
approaches  can  provide  a  better  facility  for  consistency  and  completeness  testing. 
TTiey  can  increase  the  analyzability  (of  performance,  security,  etc.)  and  testability 
of  a  system.  They  can  also  provide  the  capability  for  rapid  prototyping  and 
requirements  validation. 

3.4.3.1 .3  A  Software  Development  Process  To  Exploit  KBAs 

In  order  to  fully  exploit  knowledge-based  approaches,  the  software  development  process 

should  allow  for  the  following: 

•  Evolving  requirements  knowledge  bases.  In  procurements  it  is  often  necessary  for 
requirements  to  evolve;  therefore,  the  requirements  knowledge  base  must  also 
evolve.  In  this  case  the  process  model  should  include  an  incremental  knowledge 
acquisition  activity. 

•  Validation  and  consensus  of  the  requirements  knowledge  base.  Validation  of  the 
requirements  KB  by  software  builders,  buyers,  and  users  must  be  part  of  the  process 
model. 

•  Development  resources  planning  and  allocations.  Knowledge  engineering  requires 
a  high  up-front  investment  to  develop  and  analyze  the  knowledge  base.  If  the 
knowledge  base  can  be  reused  for  another  system,  cost  and  schedule  will  be 
significantly  reduced  for  the  next  system’s  initial  phases. 
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3.4.3.1.4  Existing  Knowledge-Based  Technology 

The  group  recommended  that  the  following  be  considered  as  examples  of  knowledge- 
based  approaches  to  requirements  engineering: 

•  ARIES 

Integrates  formal/informal  requirements 
Concepts  as  objects  in  knowledge  base 
Formal  transformation  of  requirements 

•  REFINE 

Commercial  VHLL  (Very  High  Level  Language)  specification  language 
Specification  transformation 


•  GIST 


Used  in  software  factory  project,  ARIES 
Operational  high  level  specification  language 

•  EXPRESS 

VHLL  specification  language 
Automatic  programming 

•  EVA  (Expert  System  Validation  Associate) 

Logic-based 

Meta  knowledge-based 

•  Programmer’s  Apprentice 

Basis  for  Requirements  Apprentice 
Basis  for  KBEmacs 

•  T 

Commercial  VHLL  specification  language 
Specification  transformation 
Automatic  verification 

•  KATE 

Interactive  requirements  analysis 
Requirements  specification 
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•  KIDS 

Algorithm  design 
Interactive 

•  DRACO 

Domain  level  specification 
Reuse  of  domain  knowledge 

•  Domain-specific  application  development  systems: 

WATSON  (TELEPHONY) 

Phinix  (Oil  Exploration) 

VLSI  router 

•  Foreign  efforts: 

ALVEY 

ESPRIT 

5th  generation  efforts 
3.4.3.2  Rapid  Prototyping 

The  following  questions  pertaining  to  rapid  prototyping  were  examined  by  Working 

Group  3: 

•  Who  should  do  prototyping?  What  are  the  products  of  prototyping? 

•  Do  current  regulations  and  standards  discourage  prototyping?  What  changes  to  the 
acquisition  process  are  needed  to  accommodate  prototyping? 

•  How  are  prototypes  used?  What  properties  should  a  prototype  have?  What  are 
some  examples  of  current  prototyping  tools?  What  properties  do/should  they  have? 

Some  general  insights  that  arose  during  the  discussion  of  prototyping  were: 

•  Prototyping  yields  a  competitive  edge.  Contractors  tend  to  treat  prototypes  as 
proprietary  items  because  the  prototypes  can  sometimes  provide  an  edge  in  further 
contract  competition. 

•  The  software  development  schedule  must  be  rearranged  to  allow  prototyping  to 
affect  the  final  product.  Prototyping  requires  that  more  time  be  allotted  to  the 
requirements  phase  of  development. 

•  Can  we  afford  to  prototype?  Can  we  afford  NOT  to  prototype?  Prototyping  adds 
to  the  start-up  costs  of  projecUs.  However,  the  group  feels  that  this  development 
cost  is  more  than  justified  because  prototyping  can  reduce  risks  during  system 
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development.  Prototyping  helps  to  determine  the  "correct"  requirements  from  the 
start,  increasing  the  percentage  of  system  functionality  that  is  "built  right  the  first 
time."  Also,  it  is  far  more  expensive  to  change  a  requirement  during  advanced 
development  stages,  compared  with  the  cost  of  making  the  change  in  an  earlier 
phase. 

3.4.3.2.1  Participants  and  Products  in  the  Prototyping  Process 

•  Representatives  from  every  stakeholder  group  which  perceives  a  risk  in  the 
outcome  of  the  final  system  should  be  involved  in  the  prototyping  process.  Figure  1 
portrays  the  interrelationships  between  stakeholders  in  the  development  of  a  typical 
military  system. 

•  Possible  products  of  rapid  prototyping  include: 

Formal  specifications 
Operational  prototypes 
Representation  (model)  of  requirements 
Validation  of  experimental  hypotheses 

3.4.3.2.2  Standards,  Current  Development  Practices,  and  Prototyping 

The  DoD  currently  has  the  Software  Development  Standard,  DoD-STD-2167A,  to  guide 

the  software  development  and  documentation  process. 

•  Prototyping  products  are  not  recognized.  The  products  of  prototyping  have  not 
been  recognized  as  standard  contract  deliverables.  This  makes  it  difficult  for  an 
acquisition  agency  to  require  prototyping  and  specify  what  is  to  be  delivered. 

•  Regulations  and  Standards  inhibit  innovations  such  as  prototyping.  Since  individuals 
prefer  the  security  that  compliance  with  a  standard  provides,  they  are  reluctant  to 
accept  deviation  or  change. 

•  Design  review  process  is  not  amenable  to  prototyping.  Design  reviews  currently 
have  a  well-established  structure  and  schedule  which  are  not  compatible  with  the 
evolutionary  requirements  development  process. 

•  Development  times  preclude  effective  prototyping.  Time  lines  for  current 
acquisition  projects  do  not  include  sufficient  time  in  the  requirements  process  for 
effective  prototyping. 

3.4.3.2.3  Uses,  Properties  and  Examples  of  Prototyping  Systems  and  Tools 

The  group  determined  that  prototypes  may  have  one  or  more  of  the  following  uses  and 

properties,  depending  on  the  purpose  of  the  prototype: 
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Figure  1.  Interrelationships  between  stakeholders  in  the  development  of  a  typical  military  system 


Definition  of  an  application’s  data  domain  (model),  functional  decomposition,  and 
user  interface.  The  prototype  defines  a  model  of  the  system  to  be  built.  It  depicts 
the  components  of  the  system:  the  data  and  the  functions  that  comprise  it,  and  the 
user  interface. 

Implementation  of  a  subset  of  an  application.  A  prototype  may  implement  only 
some  of  the  functionality  of  the  proposed  system  in  order  to  provide  a  rough  model 
of  how  it  will  work. 

Provision  of  a  tangible  "running"  system  for  the  stakeholders.  For  an  end  user,  the 
prototype  can  provide  a  hands-on,  interactive  representation  of  the  final  system. 
This  type  of  prototype  is  mainly  geared  towards  modeling  the  user  interface.  The 
prototj^  can  also  aid  in  the  refinement  of  requirements.  It  can  provide  a  clear 
demonstration  of  what  a  requirement  is  under  at  least  one  interpretation.  This  can 
bring  out  inconsistencies  between  stakeholders’  requirements,  providing  a  basis  for 
discussion  and  reconciliation.  For  the  developer  of  the  system,  the  prototype  can 
provide  a  tangible  model  of  the  system’s  behavior. 
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•  Allow  performance  bottleneck  prediction  within  the  operational  system  and  the 
development  project  process.  A  prototype  can  be  constructed  to  provide  a  means 
of  predicting  the  likely  bottlenecks  in  a  system,  using  alternate  designs.  It  is  not 
necessary  for  a  prototype  to  be  performance  optimized.  In  fact,  this  may  not  be  cost 
effective. 

•  Reduce  risk.  By  implementing  a  prototype,  users,  developers,  and  managers,  all 
players  pictured  in  Figure  1,  will  have  a  clearer  understanding  of  what  functions 
require  greater  effort  to  implement  than  expected.  The  risk  of  unforeseen  delays 
and  uncontrolled  costs  will  be  reduced. 

•  Serve  as  a  transition  towards  the  implementation  of  an  operational  system.  There 
was  some  disagreement  as  to  whether  or  not  systems  should  be  built  through 
successive  reflnement  of  the  prototype.  That  is,  whether  systems  should  be 
constructed  with  evolutionary  prototyping.  It  was  agreed  that  this  should  be  decided 
on  a  project-by-project  basis. 

The  group  recommended  the  following  examples  of  prototyping  tools: 

•  Data  domain  and  functional  decomposition  tools: 

4GL  RDBMS  (Fourth  Generation  Language  Relational  Database 

Management  Systems): 

ORACLE,  UNIFY. 

Integrated  CASE  tools. 

Software  through  Pictures. 

•  User  interface  definition  tools: 

Dan  Bricklin’s  DEMO,  Skylights  GX,  Videoworks,  Supercard,  Prototyper. 

TAE  Plus,  Serpent,  PROTO. 

•  Executable  specification  tools: 

RERNE,  APS,  MICROSTEP,  Stalemate. 

3.4.4  Recommendations 

Recommendations  are  divided  into  those  for  knowledge-based  techniques  and  those  for 

rapid  prototyping.  Each  section  of  recommendations  addresses  the  areas  of  management 

and  policy,  development,  and  research. 
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3.4.4. 1  Recommendations  for  Knowledge-Based  Techniques 

3.4.4.1 .1  KBA  Management  and  Policy  Recommendations 

•  Formulate  a  new  DoD  software  acquisition  policy  in  order  to: 

Allow  for  an  incremental,  evolutionary  process.  A  KBA  development  is 
typically  incremental  and  evolutionary.  Policy  must  sanction  this  methodology. 

Accommodate  KBAs  in  the  requirements  engineering  phase.  KBAs  are 
resource  intensive  on  personnel  in  the  early  phases  of  development. 

•  Develop  and  apply  new  software  process  model.  We  must  gain  practical  experience 
in  developing  and  applying  this  new,  evolutionary  model. 

•  Invest  in  KB  development  early  in  the  process.  Like  changes  in  system 
requirements  themselves,  KBAs  are  less  costly  the  earlier  in  a  project  they  are 
introduced. 

•  Reuse  knowledge  bases  in  related  projects.  The  knowledge  base  developed  for  one 
project  should  be  useful  for  future  projects. 

•  Amortize  investments  across  many  projects.  Ideally  this  would  be  done  in 
proportion  to  the  expected  payback  of  each  individual  project. 

3.4.4.1.2  KBA  Development  Recommendations 

•  Initiate  KBA  for  RE  on  a  large,  real  project.  It  is  important  that  we  gain  practical 
experience  on  a  real  project  in  order  to  determine  where  further  development 
effort  should  be  directed. 

Minimize  risk  to  the  real  project  through  use  of  a  shadow  project.  This  will 
provide  the  means  to  collect  the  necessary  data  without  negatively  impacting 
the  main  project.  The  use  of  a  shadow  project  makes  it  possible  to  collect 
enough  information  to  evaluate  errors  in  the  system  in  terms  of  the 
requirement  specifications  as  well  as  the  knowledge  base  and  the  tools  that 
use  the  knowledge  base. 

Use  the  shadow  project  to: 

•  Develop  and  apply  quality  metrics. 

•  Develop  and  apply  productivity  metrics. 

•  Perform  cost  and  benefit  analyses. 

Consider  change  impact  analysis  as  a  candidate  for  a  shadow  project. 
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*  Use  previous  experience  with  KBAs  as  input  to  future  DoD  standardization  efforts. 
Past  histoiy  will  enable  projection  and  minimization  of  the  most  probable  errors  for 
subsequent  KBA  efforts  and  provide  a  basis  for  standardization. 

3.4.4.1.3  KBA  Research  Recommendations 

*  Extend  research  in  verifleation  and  validation  (V  &  V)  techniques  by  using  KBAs 
to  test  fon 

Completeness  —  All  the  requirements  are  satisfied. 

Consistency  —  There  is  no  conflict  among  the  requirements. 

Correctness  —  Eveiy  requirement  satisfies  the  intended  user  need. 

*  Expand  research  in  knowledge  acquisition  and  management  for  RE.  We  need  to 
know  how  to  get  the  knowledge,  and  once  we  have  it,  figure  out  what  to  do  with 
it  We  also  need  to  research  configuration  management  of  knowledge  across 
products  and  projects.  The  KBs  themselves  become  resources  and  can  in  fact  be 
treated  as  commercial  items. 

*  Expand  research  in  knowledge  acquisition  and  management  in  light  of  existing 
methodologies  and  tools. 

*  Extend  research  in  more  powerful  models  with  greater  expressiveness.  There  is  a 
need  to  explore  formalisms  to  encourage  completeness  checking  in  many  different 
areas,  such  as: 

Meta-models  with  self-knowledge.  The  knowledge  base  would  have'  the 
ability  to  recursively  explore  itself. 

Non-functional  requirements.  These  include  the  so-called  "ilities,"  such  as 
maintainability,  reliability,  security,  and  performance. 

Non-standard  logics.  For  an  adequate  description  of  the  possibilities,  some 
situations  require  more  than  two  truth  values. 

Non-monotonic  logics.  Many  sets  of  requirements  cannot  admit  certain  new 
requirements  without  contradicting  previously  valid  requirements. 

Models  with  tolerance  for  inconsistency,  uncertainty,  etc.  Projects  often 
begin  with  insufficient  or  contradictory  information;  knowledge  bases  have  to 
be  able  to  handle  these  situations. 
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3.4.4.2 


Recommendations  for  Rapid  Prototyping 

Rapid  Prototyping  Management  and  Policy  Recommendations 


3.4.4.2.1 

•  Modify  the  development  stages  and  time  frames  to  be  supportive  of  prototyping. 
The  development  stages  need  to  be  redefined  and  the  amount  of  time  required  to 
complete  each  stage  needs  to  be  estimated.  There  may  be  a  need  for  a  separate 
requirements  development  phase. 

•  Define  the  objectives  of  requirements/design  reviews  for  systems  which  use 
prototyping  products.  The  use  of  a  prototype  creates  the  need  to  clarify  the 
purpose  of  a  design  review. 

^  Define  the  products  and  the  uses  of  those  products  for  prototyping  during  the 
software  development  cycle.  There  is  a  need  to  specify  the  forms  which  the 
products  should  talce  and  the  manner  in  which  they  should  be  used.  This 
information  should  be  included  within  the  appropriate  military  standard  documents 
and  guidelines  for  contract  deliverables. 

•  Support  competitive  prototyping  efforts.  Contractors  can.  and  should  be  able  to, 
compete  their  protofypes  against  each  other. 

•  Investigate  alternative  acquisition  models.  Consider,  for  instance,  different 
contractors  for  the  prototyping  effort  and  the  objective  system  development 

3.4.4.2.2  Rapid  Prototyping  Development  Recommendations 

•  Develop  training  strategies.  Develop  training  programs  for  users,  user 
representatives,  and  acquisition  personnel  to  make  them  better  aware  of  the 
prototyping  approach. 

3.4.4.2.3  Rapid  Prototyping  Research  Recommendations 

•  Conduct  research  on  the  traceability  of  requirements.  Requirements  should  be 
traceable  through  the  prototype  and  back  into  the  development  of  the  objective 
system. 

•  Conduct  research  on  the  validation  of  "non-functional"  requirements.  Prototyping 
should  support  the  validation  of  non-functional  requirements  such  as  reliability 
(criticality,  vulnerability  and  tolerance),  maintainability,  accuracy  (precision), 
performance,  timing,  speed,  and  reusability. 

•  Conduct  research  on  model  documentation.  Explore  tools  and  process  mechanisms 
which  generate  prototype  model  documentation.  These  tools  should  automatically 
document  the  user  requirements,  as  demonstrated  by  the  prototype. 
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•  Cbnduct  research  on  the  communication  of  results.  There  needs  to  be  a  formalized 
method  for  communicating  prototyping  results  betu'een  the  various  stakeholder 
groups. 

•  Conduct  research  on  the  legal  issues  of  delivery.  Contractual  vehicles  and 
responsibilities  must  be  clear  on  the  delrceiy  of  prototypes.  Different  parties  may 
have  different  expectations  of  what  the  prototype  should  be,  if  protoQpes  are  to  be 
deliverable.  There  is  a  potential  for  the  user  who  does  not  understand  the  purpose 
of  a  prototype  to  reject  it  as  being  a  deficient  system.  Conversely,  the  user  may 
want  to  Oeld  the  prototype  instead  of  the  originally  proposed  system. 

•  Conduct  research  on  the  insertion  of  prototyping  technology.  Rapid  prototyping  has 
already  caught  on.  We  must  learn  from  our  experience  in  prototyping  to  better 
answer  such  questions  as  where  in  the  life  cycle  prototyping  should  be  used  and 
what  types  of  systems  it  is  appropriate  for, 

3.4.5  Glossary 

Knowledge  Base  (KB)  -  A  repository  of  formalized  knowledge  about  some  domains  and 
areas  of  expertise. 

Knowledge-Based  Approach  (KBA)  -  A  technique  that  actively  employs  knowledge  bases 
and  knowledge-based  t(X)ls,  and  various  programming  techniques  such  as  frames  or  rules. 

Meta-model  •  As  distinct  from  a  model  of  a  particular  application,  a  model  that,  through 
knowledge  of  itself,  describes  the  properties  of,  and  the  relations  between,  any  and  all  the 
requirements  statements  of  a  system. 

Monotonic  logics  -  Logics  in  which  the  addition  of  new  axioms  does  not  invalidate 
previously  proved  theorems. 

Non-functional  requirements  -  Requirements  that  are  not  directly  related  to  a  particular 
function.  Some  examples  include:  reliability,  availability,  maintainability,  security,  ease  of 
use,  ease  of  learning,  and  performance. 

Non-monotonic  logics  •  Logics  that  are  not  monotonic. 

Non-standard  logics  -  Logics  with  more  than  two  truth  values. 

Requirements  Engineering  (RE)  ~  A  systematic  method  for  developing  quantiiiabie  and 
testable  requirements. 

Shadow  Project  -  A  separate,  funded,  research-like  project  that  runs  in  parallel  with,  but 
does  not  impact  upon,  the  main  project. 
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3.4.6 


Referenced  Documents 


Barr,  A.  and  Cohen,  P.,  The  Handbook  of  Artificial  Intelligence.  Vol.  IV.  New  York: 
Addison-WesI^,  19^. 


73 


3.5 


Recommendations  and  Conclusions 


The  workshop  produced  many  valuable  insights  and  recommendations.  These  insights  and 
recommendations  are  fully  documented  in  these  Proceedings.  It  is  especially  important  to 
note  the  recommendations  that  were  common  to  the  three  groups,  which  worked 
independently. 

3.5.1  DoD  Policy  Changes.  Every  group  saw  the  need  for  DoD  to  change  policy  to 
accommodate  evolutionary  acquisition. 

•  Working  Group  One  recommended  DoD  "make  changes  to  acquisition  policies  and 
DoD  standards  to  facilitate  evolutionary  acquisition." 

•  Working  Group  Two  proposed  DoD  "change  acquisition  policies  and  management 
practice  to  support  a  requirements-centered  development  life  cycle  model." 

•  The  third  working  group  recommended  DoD  "formulate  a  new  DoD  software 
acquisition  policy  in  order  to  allow  for  an  incremental,  evolutionary  process  ..." 
Further  DoD  needs  to 

...modify  the  development  stages  and  time  frames  to  be 
supportive  of  prototyping.  The  development  stages  need  to  be 
redefined  and  the  amount  of  time  required  to  complete  each 
stage  needs  to  be  estimated.  There  may  be  a  need  for  a 
separate  requirements  development  phase. 

In  sum,  we  should  "consider  alternative  acquisition  models." 

3.5.2  Government  Acquisition  Personnel  Training.  All  groups  saw  the  need  for  increased 
training  for  Government  acquisition  personnel  to  make  them  more  aware  of 
Requirements  Engineering  issues  and  techniques. 

•  Working  Group  One  recommended  DoD  "educate  contracting  officers  and  their 
technical  representatives  on  the  evolutionary  acquisition  approach;  emphasize  that 
system  requirements  can  not  be  fully  defined  a  priori;  and  that  requirements 
engineering  is  continuous  throughout  the  life  cycle  of  the  system."  DoD  must 
"educate  program  managers  and  team  members  that  ’changing  your  mind’  as  a  result 
of  new  information  is  acceptable."  DoD  must  "train  Government  program  managers 
in  the  use  of  acquisition  models  that  employ  prototyping." 

•  Working  Group  Two  proposed  DoD  "increase  training  of  management/acquisition 
personnel  in  Requirements  Engineering."  DoD  should  also  "establish  an 
Information/consultation  center  on  requirements  engineering  (process,  methods, 
tools,  and  metrics.)" 
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•  The  third  group  recommended  DoD  "develop  training  programs  for  users,  user 
representatives,  and  acquisition  personnel  to  make  them  better  aware  of  the 
prototyping  approach." 

3.5.3  Requirements  Validation.  Every  group  saw  the  need  for  additional  emphasis  and 
exploration  in  requirements  validation. 

•  Working  Group  One  recommended  DoD  "develop  an  explicit  requirements 
validation  plan  for  every  project" 

•  Working  Group  Two  recommended  research  for  "coupling  working  models  to 
real-world  stimuli;  enabling  dynamic  analysis  through  animation  of  requirements 
statements,  especially  time  based  analysis;  and  greater  focus  on  long-term  research, 
such  as  for  theorem  provers." 

•  The  third  working  group  proposed  research  into  how  prototyping  can  "support  the 
validation  of  non-functional  requirements  such  as  reliability  (criticality,  vulnerability, 
and  tolerance),  maintainability,  accuracy  (precision),  performance,  timing,  speed, 
and  reusability." 

3.5.4  Measuring  Requirements  Related  Attributes  and  Progress.  Most  of  the  participants 
recognized  the  need  for  additional  research  in  defining  and  using  methods  of  measuring 
requirements  related  attributes  and  progress  in  the  Requirements  Engineering  process. 

•  Working  Group  One  recommended  "DoD  develop  and  use  effective  metrics  to 
measure  requirements  progress  and  completion." 

•  Working  Group  Two  saw  the  need  for  DoD  to  "determine  and  develop  meaningful 
metrics  supporting  modem  requirements  engineering  practice.  ...A  number  of 
requirements  attributes  need  to  be  quantified;  methods  and  metrics  are  needed." 

3.5.5  Non-Functional  Requirements.  Most  identified  the  need  for  further  work  in  specifying 
non-functional  requirements. 

•  Working  Group  Two  emphasized  in  several  places  the  need  to  better  address 
non-functional  requirements.  They  stated  DoD  must 

develop  methods  to  capture,  integrate,  and  measure  the 
so-called  non-functional  requirements.  There  needs  to  be  R&D 
for  how  to  specify  non-functional  requirements.  In  particular, 
we  need  methods  and  tools  to:  support  conflict  resolution,  e.g., 
maintainability  vs.  reliability;  enable  specifying  ’degree  of,  e.g., 
quantifying,  such  as  levels  of  security:  help  identify 
relationships  among  the  'ilities';  model  with  wide  applicability, 
e.g.,  scale  up  kinds  of  current  modeling.  ...Research  is  needed 
to  learn  how  to  capture  non-functional  requirements  to  the 
extent  that  the  impact  to  proposed  changes  in  a  non-functional 
requirement  can  be  predicted. 
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Methods  for  ’ilities  -  driven  engineering  methods  need  to  be  developed.  "A  number 
of  ’ilities’,  chief  among  them  maintainability  (or  flexibility  to  change),  need  to  be 
built-in  to  requirements  as  special  items  to  be  considered  throughout  the 
requirements  engineering  process."  DoD  must  develop 

...first  a  template  to  identify  the  non-functional  requirements ... 
in  order  to  keep  them  from  falling  through  the  cracks ...  Tools 
and/or  languages  to  evaluate  and  express  these  non-functional 
requirements  are  vital  to  this  ever  important  requirements  data 
base. 

In  their  language  section,  Working  Group  Two  proposed  the  need  for  research  to 
"solve  the  problem  of  defining  the  so-called  ’non-functional’  requirements." 

•  Working  Group  Three  proposed  for  DoD  to 

explore  formalisms  to  encourage  completeness  checking  in 
many  different  areas  such  as  ...  non-functionai  requirements. 

These  include  the  so-called  'ilities',  such  as  maintainability, 
reliability,  security,  and  peifomianca.  ...  research  how 
prototyping  can  support  the  validation  of  non-functional 
requirements ... 

3.5.6  Requirements  Trade-off  Analysis.  Two  working  groups  saw  the  need  for  additional 

work  in  requirements  trade-off  analysis. 

•  Working  Group  One  recommended  "DoD  develop  tools/techniques  to  capture 
merits/trade-offe  among  requirements." 

•  Working  Group  Two  stated  "tools  and  techniques  are  needed  to  capture,  organize, 
and  help  evaluate  the  many  trade-offs  that  occur  in  requirements  development. 
Intelligent  impact  analysis  is  an  example." 

3.5.7  Requirements  Traceability.  Additional  research  in  requirements  traceability  was  also 

suggested. 

•  Working  Group  Two  proposed  a  "life  cycle  requirements  database  to  capture  and 
manage  attributes  of  individual  requirements  and  provide  traceability". 

•  Working  Group  Three  emphasized  the  need  for  research,  stating,  "requirements 
should  be  traceable  through  the  prototype  and  back  into  the  development  of  the 
objective  system". 

3.5.8  Multiple  Stakeholder  Issues.  Special  emphasis  was  given  to  multiple  stakeholder  issues. 

•  Working  Group  One  devoted  an  entire  section  of  its  report  on  the  need  to  reach 
closure  among  multiple  stakeholders. 
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Working  Group  Three  recommended  the  development  of  "formalized  methods  for 
communicating  prototype  results  between  the  various  stakeholder  groups." 


3.5.9  Technology  Application.  Hnally,  and  most  obviously,  the  workshop  concluded  that  it 
is  not  enough  to  merely  research  and  develop  technologies.  DoD  must  constantly  seek 
ways  to  apply  those  technical  gains  in  the  real  world. 
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Workshop  Agenda  -  Day  One 
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9:10  -  9:35  Technical  Presentation  1 
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11:10  - 11:35  Technical  Presentation  5 

Dr.  Alan  M.  Davis 
George  Mason  University,  USA 
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International  Software  Systems,  USA 
"Framework  for  the  Requirements  Process" 
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1:30  -  1:40  Workshop  Charge 

Mr.  George  Sumrall 
TTCP  Workshop  Chairperson 

1:40  -  1:50  Working  Group  1  Overview 
Dr.  Alan  M.  Davis 
Working  Group  1  Chairperson 

1:50  -  2:00  Working  Group  2  Overview 
Dr.  Raymond  T.  Yeh 
Working  Group  2  Chairperson 

2:00  -  2:10  Working  Group  3  Overview 
Dr.  Winston  W.  Royce 
Working  Group  3  Chairperson 

2:10  -  5:30  Working  Group  Activities 

5:30  -  6:00  Meeting  -  Working  Group  Chairpersons 

7:00  Group  Dinner 
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Workshop  Agenda  -  Day  Two 
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8:30  -  8:55  Technical  Presentation  7 

Mr.  Douglas  A.  White 
Rome  Air  Development  Center,  USA 
"Knowledge-Based  Requirements  Assistant" 

8:55  -  9:20  Technical  Presentation  8 

Mr.  Michael  Deutsch 
Software  Engineering  Institute,  USA 
"Insights  Into  the  Influence  of  Shared 
User/Customer/Contractor  Objectives  on  Project  Success" 

9:20  -  9:45  Technical  Presentation  9 

Mr.  Reed  Little 

Carnegie-Mellon  University,  USA 

"The  Serpent  User  Interface  Management  System" 
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Mr.  Martin  Morel 
Le  Groupe  CGI,  Canada 

"A  Prototyping  Methodology  Applied  to  Tactical  C2  Systems" 
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Mr.  William  E.  Rzepka 
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1:15-  5:30 
5:30-  6:00 
5:30-  9:00 
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Working  Group  Activities 

Meeting  -  Working  Group  Chairpersons 

Optional  Working  Group  Activities 


A-6 


Workshop  Agenda  -  Day  Three 
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Working  Group  1  Report 
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TCCP  Workshop  Chairperson 


A-7 


This  page  is  intentionally  left  blank. 


A-8 


APPENDIX  B 


Attendee  Directory 


This  page  is  intentionally  left  blank. 


B-2 


Attendee  Directory  Information 


Dr.  Stephen  J.  Andriole 
George  Mason  University 

Department  of  Information  Systems  and  Systems  Engineering 
4400  University  Drive 
Fairfax,  Virginia  22030 
(703)  764-6751 

Mr.  David  Bagley 

CECOM  Center  for  Software  Engineering 
ATTN:  AMSEL-RD-SE-AST-SE 
Fort  Monmouth,  New  Jersey  07703-5000 

(201)  532-2081 

Mr.  Joseph  Batz 

United  States  National  Leader  and  Chairperson,  XTP-2 
Software  Engineering  /  DOD  -  DDRE  (R&AT)  SCT 
Software  and  Computer  Technology 
3E114  The  Pentagon  /  OUSDA 
Washington,  District  of  Columbia  20301-3081 

(202)  694-0212 

Mr.  Harlan  Black 

CECOM  Center  for  Software  Engineering 
US  Army  HQ  CECOM 
ATTN:  AMSEL-RD-SE-AST-SE 
Fort  Monmouth,  New  Jersey  07703-5000 
(201)  544-2238 

Mr.  Philip  Casey 
US  Army  HQ  TRADOC 
ATTN:  ATCD-CB  (Casey) 

Fort  Monroe,  Virginia  23651 
(804)  727-3271 

Mr.  Robert  N.  Charette 
ITABHI  Corporation 

9840  Main  Street  /  Suite  201  FACSIMILE  #:  (703)  352-1592 

Fairfax,  Virginia  22031 
(703)  352-1566 


FACSIMILE  #:  (201)  532-4129 
AMSEL-RD-SE-AST@CECOM-2.ARPA 
AUTOVON  #:  992-2238 


JBATZ  @  AJPO.SEI.CMU.EDU 
AUTOVON  #:  224-0201 


B-3 


Mr.  Edward  R.  Comer 
Software  Productivity  Solutions,  Inc. 

P.O.  Box  361697 
Melbourne,  Horida  32936-1697 

(407)  984-3370 

Mr.  Thomas  P.  Conrad 
Naval  Underwater  System  Center 
Code  2211  /  Building  1171 
Newport,  Rhode  Island  02841-5047 
(401)  841-3353 

Dr.  Alan  M.  Davis,  Working  Group  Chairperson 

George  Mason  University 

ISSE  Department 

4400  University  Drive 

Fairfax,  Virginia  22030-4444 

(703)  323-2792 

Mr.  Michael  S.  Deutsch 
Hughes  Aircraft  Co. 
c/o  Software  Engineering  Institute 
Carnegie-Mellon  University 
Pittsburg, Pennsylvania  15213 
(412)  268-7047 

Mr.  Robert  C.  Fink 
Performance  Resources,  Inc. 

5111  Leesburg  Pike  /  Suite  301 
Falls  Church,  Virginia  22041 
(703)  845-9600 

Mr.  Gary  E.  Fisher 
NIST  /  NCSL 

Technology  Building  Room  B266 
Gaithersburg,  Maryland  20878 

Mr.  Harrison  D.  Fountain 
US  Naval  Post  Graduate  School 
Computer  Science  Department 
Monterey,  California  93943 

(408)  646-2461 

Dr.  William  Gilmore 
International  Software  Systems,  Inc. 

9420  Research  Blvd.  /  Suite  200 
Austin,  Texas  78759 
(512)  .338-5711 


ECOMER  @  AJPO.SEI.CMU.EDU 


FACSIMILE  #:  (401)  841-4749  ■ 
TCONRAD  @  NUSC.ADA.ARPA 
AUTOVON  #:  948-3353 


FACSIMILE  #:  (703)  323-2630 
ADAVIS  @  GMUVAX.GMU.EDU 


FACSIMILE  #:  (412)  268-5758 
MSD@  SEI.CMU.EDU 


FACSIMILE  #:  (70.3)  671-7522* 


nSHER@SWE.NCSL.NIST.GOV 


FACSIMILE  #:  (512)  338-5757 
GILMORE  ©ISS.UUCP 


B-4 


Dr.  Cordell  Green 
Kestrel  Institute 
3260  Hillview  Avenue 

Palo  Alto,  California  94304  GREEN@KESTREL.EDU 

(415)  493-6871 

Ms.  Margaret  Hamilton 
Harriilton  Technologies,  Inc. 

17  Lnman  Street 

Cambridge,  Massachusetts  02139 
(617)  492-0058 

Mr.  David  R.  Harris 
Sanders  Associates,  Inc. 

95  Canal  Street,  NCAl-2232 
Nashua,  New  Hampshire  03061 
(603)  885-9182 

Mr.  Donald  C.  Harris  Jr. 

Directorate  of  Combat  Development 
Tactical  Software  Division 
Comdt,  USAADASCH 
ATTN:  ATSA-CDS  (Harris) 

Ft.  Bliss,  Texas  79916-7050 

(915)  568-2810/4431  AUTOVON  #:  978-2444 

Mr.  Robert  L.  Harris 
US  Air  Force 

WRDC/AAAF-3  Attn:  R.  Harris 

Wright  Patterson  AirForce  Base,  Ohio  45433-6543  AUTOVON  #:  785-3947 

(513)  255-3947 

Dr.  Pei  Hsia 

University  of  Texas  Arlington 
Computer  Science  Engineering  Department 

P.O.  Box  19015  FACSIMILE  #:  (817)  273-2548 

Arlington,  Texas  76019  HSIA  @  EVAX.ARL.UTEXAS.EDU 

(817)  273-3785 

Mr.  James  Huskins 
US  Naval  Post  Graduate  School 
Computer  Science  Department 
Monterey,  California  93943 
(408)  646-2461 


B-5 


Dr.  W.  Lewis  Johnson 
University  of  Southern  California  /  ISI 
4676  Admiralty  Way  /  Suite  937W 
Marina  del  Rey,  California  90291 
(213)  822-1511 

Mr.  Jean-Claude  Labbe 

Defence  Research  Establishment,  Valcartier 

P.O.  Box  8800 

Courcelette,  Quebec 

Canada,  GOA  IRQ 

(418)  844-4346 

Mr.  Aaron  Larson 
Honeywell,  Inc. 

Systems  and  Research  Center  MN65-2100 
3600  Technology  Drive 
Minneapolis,  Minnesota  55418 
(612)  782-7340 

Mr.  Reed  Little 
Software  Engineering  Institute 
Carnegie-Mellon  University 
Pittsburgh,  Pennsylvania  15213 
(412)  268-5792 

Mr.  Michael  J.  Looney 
AXC4,  BLK3,  ARE(PN) 

Portsmouth. 

P06  4AA,  UK 
0705  219999  Ext.  2330 

Cpt  Gary  W.  Manley 
US  Naval  Post  Graduate  School 
Computer  Science  Department 
Spanagel  Hall  MS:52LQ 
Monterey,  California  93943 
(408)  544-2670 

Mr.  Walter  Marks 

CECOM  Center  for  Software  Engineering 
ATTN:  AMSEL-RD-SE-AST-SE 
Fort  Monmouth,  New  Jersey  07703-5000 
(201)  532-2146 


JOHNSON  @  ISI.EDU 


FACSIMILE  #:  (418)  844-4538 
LABBE  @  JUPITER.DREV.DND.CA 


LITTLE  @  SEI.CMU.EDU 


MANLEY  @  CS.NPS.NAVY.MIL 


AUTOVON  #:  992-2146 


B.6 


Mr.  Raymond  Menell 

CECOM  Center  for  Software  Engineering 

ATTN:  AMSEL-RD-SE-AST-SE 

Fort  Monmouth,  New  Jersey  07703-5000 

(201)  532-2343 

Mr.  Martin  Morel 
Le  Groupe  C.G.I 
5300  Boulevard  Des  Galeries 
Quebec,  P.Q. 

Canada  G2K  2A2 
(418)  623-0101 

Dr.  Peter  Ng 

New  Jersey  Institute  of  Technology 
Department  of  Computer  &  Information  Science 
323  Dr.  Martin  Luther  King  Blvd. 

Newark,  New  Jersey  07102 
(201)  596-3387  /  3366 

Mr.  Scott  P.  Overmyer 
Contel  Technology  Center 
1500  Conference  Center  Drive 
P.O.  Box  10814 
Chantilly,  Virginia  22021-3808 
(703)  818-4480 

Mr.  Mark  A  Podracky 
Digital  Fantacies,  Ltd 
2230  Gallows  Road  /  Suite  240 
Dunn  Loring,  Virginia  22027 
(703)  698-9455 

Mr.  Robert  M.  Poston 
Programming  Environments  Inc. 

4043  State  Hwy  33 

Tinton  Falls,  New  Jersey  07753 

(201)  918-0110 

Mr.  Glenn  E.  Racine 
AIRMICS  (US  Army) 

115  O’Keefe  Building 
Georgia  Tech 

Atlanta,  Georgia  30332-0800 
(404)  894-3110 


AUTOVON#:  992-2343 
FACSIMILE#:  (201)  532-4129 


FACSIMILE  #:  (418)  623-4114 


FACSIMILE  #:  (201)  596-5777 
NG-P@VIENNA.NJST.EDU 


OVERMYER  @  CTC.CONTEL.CON 


FACSIMILE  #:  (201)  918-0113 


FACSIMILE  #:  (404)  894-3142 
RACINE  @  AIRMICS.ARMY.MIL 


B-7 


Dr.  Winston  W.  Royce 
SoftwareFirst 
22534  Paul  Revere  Drive 
Woodland  Hills,  CA  91364 
(818)  887-1811 

Mr.  William  Rzepka 

Rome  Air  Development  Center 

RADC/COEE/ Building  3 

Griffiss  Air  Force  Base,  New  York  13441-5700 

(315)  330-2762 

Dr.  Donaldine  Samson 
Weber  State  College 
Ogden,  Utah  84408-3804 
(801)  626-7189 

Mr.  Edward  H.  Schlosser 
Lockheed  Software  Technology  Center 
2100  East  St.  Elmo  Road, 

Bldg  30E,  Organization  96-10 
Austin,  Texas  78744 
(512)  327-3672 

Dr.  Carl  A.  Singer 
Bellcore 

6  Corporate  Place 

Room  PYA-1K282 

Piscataway,  New  Jersey  08854-4158 

(201)  699-8951 

Dr.  Victor  Conrad  Sobolewski 
Government  of  Australia 
1601  Massachusetts  Avenue  NW 
Washington,  District  of  Columbia  20036 

(202)  797-3378 

Dr.  Rolf  Stachowitz 
Lockheed 

2100  E.  St.  Elmo  Road 
0/96-10,  B/30E 
Austin,  Texas  78744 
(512)  448-5772 


RZEPKAW  @  LONEX.RADC.AF.MIL 
AUTOVON  #:  587-2762 


DSAMSON  @  UTAH.CC.COM 


SCHLOSSER  (SSTCLOCKHEED.COM 


BELLCORE  @  PYUXEISINGER 
FACSIMILE  #:  (201)  562-9305 


FACSIMILE  #:  (202)  797-3326 
AUSDEF  @  A.ISI.EDU 


FACSIMILE  #:  (512)  448-5728 
ROLF  @  LOCKHEED.COM 


B-8 


Mail:  Dr.  Rolf  Stachowitz 
c/o  WW  Royce 
22534  Paul  Revere  Drive 
Woodland  Hills,  Ca.  91364 
(818)  887-1811 

Mr.  George  Sumrall,  Workshop  Chairperson 
CECOM  Center  for  Software  Engineering 
ATTN:  AMSEL-RD-SE-AST-SE  (Sumrall) 

Fort  Monmouth,  New  Jersey  07703-5000 
(201)  532-2342 

Dr.  Murat  M.  Tanik 
Southern  Methodist  University 
Computer  Science  Department 
SMU,  Dallas,  Texas  75275 
(214)  692-2854 

Mr.  James  Toher 
SD-SCICON 
Pembroke  House 
Pembroke  Broadway 
Camberley,  Surrey 
GUI5  3XD,  England 

Mr.  David  H.  Watjen 
Advanced  Technology,  Inc. 

2  Crystal  Park 

2121  Crystal  Drive  /  Suite  200 
Arlington,  Virginia  22202 
(703)  769-3000 

Mr.  Douglas  A.  White 
US  Air  Force 

Rome  Air  Development  Center  RADC/COES 
Griffiss  Air  Force  Base,  New  York  13438-5700 
(315)  330-3564 

Dr.  Martin  I.  Wolfe,  Member  XTP-2 
CECOM  Center  for  Software  Engineeing 
ATTN:  AMSEL-RD-SE-AST  (Wolfe) 

Fort  Monmouth,  New  Jersey  07703-5000 
(201)  532-2423 


FACSIMILE  #:  (201)  532-4129 
SUMRALL  @  AJPO.SEI.CMU.EDU 
AUTOVON  #:  992-2342 


WHITE  @  AIVAX.RADC.AF.MIL 
AUTOVON  #:  587-3564 


FACSIMILE  #:  r201)  532-4129 
MWOLFE  @  A.ISI.EDU 
AUTOVON  #:  992-2423 


B-9 


FACSIMILE  #:  (512)  338-5757 


Dr.  Raymond  T.  Yeh,  Working  Group  Chairperson 
International  Software  Systems,  Inc. 

9420  Research  Blvd.,  Suite  200 
Austin,  Texas  78759 
(512)  338-5700 


B-10 


APPENDIX  C 


Letters  from  Chairpersons 


Note:  The  following  letters  were  sent  by  each  of  the  Working  Group 
Chairpersons  to  the  workshop  participants  in  their  respective 
Working  Groups,  prior  to  the  workshop. 


This  page  is  intentionally  left  blank. 


C-2 


For  the  Participants  of  Working  Group  1 
From  Dr,  Alan  M.  Davis 


Statement  of  Goals 

The  term  "process"  in  our  title  implies  that  we  will  be  limiting  our  discussion  to  the  activities,  events 
and  procedures  that  occur  in  the  creation  and  evolution  of  system  and  software  requirements.  Given 
this  immense  charter  and  the  vast  combined  experiences  of  the  members  of  this  working  group,  it  is 
clear  that  we  could  probably  attack  any  one  requirements  process-related  topic  and  discuss  it  for 
seven  (7)  hours.  However,  our  goals  are  to  cover  the  full  spectrum  of  the  requirements  process 
domain,  not  just  to  delve  onto  a  set  of  specific  topics.  The  general  goal  is  easy:  At  the  completion 
of  the  second  day,  every  group  member  .should  have  a  clearer,  more  focused,  view  of  all  aspects  of 
the  requirements  process.  Here’s  a  strawman  set  of  specific  technical  goals  that  we  want  to  achieve 
by  the  end  of  the  second  day  of  the  workshop. 

1.  Identify,  clarify,  and  prioritize  the  issues  relating  to  the  requirements  process.  Note 
that  this  is  a  breadth-first  analysis  of  the  requirements  process  domain.  We  will  be 
asking  lots  of  questions,  not  necessarily  answering  them. 

2.  What  are  the  possible  positions  on  each  of  the  issues  that  we  come  up  with?  Note 
we  need  not  agree  to  one  position,  but  we  do  need  to  agree  as  to  what  the 
alternatives  are. 

3.  Enumerate  efforts  to  date  to  resolve  some  of  the  issues.  What  have  they  shown?  Are 
the  results  conclusive?  What  limitations  do  the  results  have? 

4.  What  additional  work  needs  to  be  completed  to  resolve  the  issues? 

5.  Debate  and  reach  group  consensus  on  one  or  more  of  the  issues. 


Preliminary  List  of  Issues 

1.  }Vhat  are  requirements  and  requirements  engineering?  Do  they  include  user  needs  analysis? 
Problem  analysis?  Description  of  the  external  behavior  of  the  system  to  be  built/procured? 
Definition  of  the  system’s  constituent  components?  Do  they  end  at  the  beginning  of  the 
design  phase?  How  do  they  relate  to  the  requirements  changes  that  occur  throughout  the 
life  cycle? 

2.  }Vhat  are  the  relationships  among  system  requirements,  systems  design,  software  requirements  and 
the  acquisition  life-cycle? 

3.  Is  there  such  a  thing  as  a  "perfect"  requirements  process?  For  all  software?  For  any  application 
area?  For  any  particular  effort?  Must  the  process  itself  be  flexible  so  that  the  process 
changes  as  new  information  is  learned  about  the  lequircments  themselves? 
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4.  }Yhat  are  the  constituent  primitive  elements  that  make  up  any  requirements  process?  Do  such 
elements  exist?  If  so,  which  are  essential  to  any  requirements  process?  Which  are  optional? 
What  are  the  ways  of  combining  them  to  form  valid  requirements  process  models?  As  an 
alternative,  perhaps  a  better  approach  to  defining  all  possible  requirements  process  models 
is  to  first  define  all  elements  of  the  product  of  any  requirements  process. 

5.  Recognizing  that  requirements  engineering  encompasses  all  aspects  of  the  handling  of 
requirements  regardless  of  when  they  occur,  how  does  a  requirements  process  interface  with 
configuration  management  processes  that  are  designed  to  accommodate  change  (including 
requirements  changes)  during  development?  Are  there  other  considerations  to  accommodate 
inevitable  changes  to  requirements  once  the  requirements  are  baselined?  When  should 

,  requirements  be  baselined? 

6.  }Vhat  does  it  mean  to  validate  requirements?  How  can  it  be  done?  When  should  it  be  done? 


Suggested  Reading  Material 


Yeh,  Raymond,  T.,  "Requirements  Analysis  -  A  Management  Perspective,"  pp.410-416. 


Davis,  Alan,  M.,  "A  Taxonomy  for  the  Early  Stages  of  the  Software  Development  Life  Cycle,"  The 
Journal  of  Systems  and  Software.  Vol.  8,  No.  4,  September,  1988,  pp.  297-311. 


Harel,  David,  "Statecharts:  A  Visual  Formalism  for  Complex  Systems,"  Science  of  Computer 
Programming.  Vol.  8,  1987,  pp.  1-29. 
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For  the  Participants  of  Working  Group  2 
From  Dr,  Raymond  T,  Yeh 


A  Brief  Description  of  the  Issues 

Although  much  research  work  has  been  performed  on  requirements  analysis,  most  published  literature 
is  concerned  with  tools,  methods  or  notations,  without  asking  to  which  extent  they  can  be  used  in 
conjunction  in  order  to  support  each  other.  I  believe  that  an  integrated  perspective  is  necessary  in 
order  to  attain  the  goal  of  this  workshop.  The  following  diagram  provides  major  areas  of  concern 
in  the  requirement  phase.  The  interrelationship  between  components  forms  the  foundation  for  an 
integrated  approach. 


Figure  1.  An  Integrated  View  of  Requirements 
Engineering. 


The  requirements  analysis  phase  itself  is  split  into  a  subphase  concerned  with  studying  the 
requirements  of  the  complete  system  to  be  developed  (hardware,  software  and  organizational 
environment,  functional  and  non-functional  aspects),  a  subphase  during  which  the  boundary  between 
hardware  and  software  and  organizational  aspects  of  the  new  system  is  defined,  and  a  set  of 
potentially  parallel  subphases  during  which  the  particular  hardware  requirements,  software 
requirements  and  organizational  requirements  are  analyzed.  Finally,  requirements  aspects  to  be  best 
addressed  during  later  phases  of  the  life  cycle  need  mentioning. 
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For  each  of  the  phases  and  subphases  mentioned  above,  concrete  objectives  are  set.  Further,  the 
following  questions  need  to  be  answered: 

.  •  What  are  the  particular  steps  taken  and  methods  to  be  used  during  this  subphase? 

•  What  information  is  needed  as  input  for  this  phase? 

•  What  kind  of  analysis  should  be  performed  on  this  information  to  verify  its  truth? 

•  How  should  this  information  be  documented? 

•  What  are  the  exit  criteria  for  each  phase? 

•  What  tools  are  needed  to  support  this  phase  or  what  are  the  desirable  properties  of 
such  tool? 

I  would  like  to  see  our  group  with  three  subgroups:  methodology,  language,  and  tools.  The 
methodology  group  will  be  concerned  with  most  of  the  questions  raised  above.  For  the  language  group, 
I  suggest  to  look  at  the  possibility  of  a  common  CORE  for  various  requirements  languages  as  shown 
in  Figure  2.  Is  the  CORE  language  a  real  language  or  simply  a  common  schema,  e.g.,  semantic  net? 


Figure  2.  A  System  of  Requirements  Languages 


For  the  tools  group,  I  suggest  looking  at  the  integration  issues.  How  can  various  tools  be  effectively 
integrated.  Note  that  we  have  traditional  tools  as  well  as  state-of-the-art  tools.  Clearly,  this  issue 
is  very  much  linked  with  the  language  issue. 
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TO:  George  Sumraii;  All  UJoiKing  Group  5  Participants 

FROM:  UJIn  Royce 

SUBJECT:  Plan  for  Ulorking  Group  3,  Technical  Panel  on 

Software  Engineering,  NouemPer  1 4  through  NouemPer  1 6 


marking  Group  5  is  assigned  the  task  of  analyzing  prototyping  and 
knoujledga-hased  techniques  as  applied  to  requirements  engineering. 

lUe  haue.  at  most,  two  days  to  complete  our  task.  To  quickly  focus  on  the 
issues  and  then  resolue  them,  1  am  proposing  the  following  approach.  The 
working  group  will  jointly  construct  eight  to  ten  well'posed  questions 
couenng  the  most  critical  issues  of  our  assigned  subject.  These  questions, 
will  be  prioritized:  and  suhstantiaily  more  time  will  be  atlocated  to 
analysis  of  the  higher  priority  questions.  Each  question  will  be  analyzed 
in  two  succeeding  sessions.  The  first  session  will  brainstorm  the 
questions  attempting  to  capture  all  ideas  (euen  conflicting  ones!  that 
might  be  of  ualue.  The  second  session  will  aim  at  winnowing  down  these 
raw.  possibly  conflicting  ideas  to  a  shorter,  consensus-achieumg  set  wite 
associated  features,  benefits,  and  actions.  R  third  session  is  scheduled  to 
complete  our  paperwork  and  a  fourth  session  to  report  out  our  findings. 

The  four  working  group  sessions  are  organized  as  follows: 
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seMion  tt  fl  3-!/2  hour  long  planning  and  brainstorming' 

session  to  answer  8  to  1 0  questions  at  an  auerage  rate  of  1 5  minutes  per 
question. 

Session  ii!  8  4  hour  long  concentration  on  uiord-smithing 

sharpiy-honed  answers  to  the  questions  based  on  benefits,  features,  and 
actions.  The  auerage  time  for  each  answer-creating  response  wiil  be  iesr 
than  20  minutes  per  question. 

Session  III!  8  2  hour  long  session  to  write  up  our  findings.  8t 
least  one-half  of  our  written  inputs  wiil  haue  already  been  done  in 
realtime  during  sessions  i  and  It. 

Session  tu:  8  1  hour  tong  briefing  on  our  findings  by  a  worlctng 

group  spokesperson  to  the  assembled  participants  from  all  working 
groups. 

Succeeding  sections  of  this  plan  include: 

-a  listing  of  f  4  potential  questions 
-detailed  instructions,  agendas,  and  schedules  for 
sessions  i,  II,  and  ill 

-instructions  for  prepanng  the  working  group 
summary  document 

The  14  potential  questions  listed  In  the  nent  sections  are  intended  to 
stimulate  the  pre-workshop  thinking  of  the  forking  Group  111 
participants.  Each  participant  ought  to  reuiew  the  potential  questioner- 
included  here,  reword  them  to  be  more  sharply-put,  or  Inuent  their  oum^ 
questions  for  consideration  and  bring  them  to  session  i  in  a  form  ready  to  ' 
distribute  to  the  other  participants.  The  first  Item  of  business  in  session  I 
will  be  to  select  a  set  of  questions  and  prioritize  them.  This  selected  set 
of  prioritized  questions  will  become  the  principal  mechanism  which 
organizes,  focuses  and  otherwise  guides  ail  further  deliberations  of  our 
working  group.  Selecting  the  right  set  of  questions  is  important.  (If  no 
participant  acts,  the  questions  included  In  the  following  section  will  serve 
as  the  default  set  to  guide  us.) 
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lUhy  are  uie  deuoting  66  hours  of  our  professional  Hues  to  prototyping, 
and  knoufiedge-hased  approacnes  to  requirements  enyineenng?  Because 
it  it  importanti  The  accompanying  figure  proposes  one  reason  as  to  uihg 
our  iponc  ts  important:  if  there  are  other  reasons  they  ought  to  he 
uncouereo  during  the  critical  nine  hours  of  our  joint  deiiherations.  The  8 
to  IQ  questions  uihich  me  mill  choose  to  concentrate  on  are  best 
ansmereo  if  me  also  understand  mhy  me  are  asking  them. 

Keep  in  mind  that  each  participant  mill  haue  no  more  than  tmo  minutes 
per  question,  per  session,  to  make  his  point,  me  must  ail  be  prepared, 
focused,  consensus-oriented  and  especially  articulate  (and  fast  mriterr 
tool  if  me  are  going  to  complete  our  assigned  task. 

See  you  in  Nouemberi 


min  Royce 
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IIIHHT  IS  THE  PRIMRRV  ISSUE  ORIUING  REmilREMENTS  ENGINEERING? 


C-IO 


Figure  I :  qui)  jqsK  IS  IMfORTHNTI 


-4- 


Queations  for  Prototunino 

•Ulhat  qualities  must  a  prototyping  system  tiaue?  Ulhat  problems 
must  it  solue?  In  the  short  term?  In  the  longer  term? 

-Ulhat  are  the  best  current  euamples  of  prototyping  systems? 

-Houi  does  the  softuiare  development  process  have  to .  be^ 
constructed  to  eupioit  prototyping  ? 

-Should  major  softuiare  acquisition  agencies  (e.g.,  gouemmentsi 
mandate  prototyping  ? 

-Houi  does  the  user  and  the  acquisition  agency  interact  uiith  the 
prototyping  system  during  deuelopment? 

•Qoes  the  construction  of  prototyping  systems  have  especially 
difficult  deuelopment  problems?  Ulhat  are  they?  Should  the  research 
community  be  stimulated  to  help? 

-Hre  prototyping  systems  going  to  be  easy  to  use?  Is  special 
training  required?  Hre  there  technology  transfer  problems? 
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Session  Tuesdau  2:0n“5;50 

Thiit  first  one-fiaif  hour  will  be  concentrated  on  getting  organized  plus 
reuieuiing  the  schedule.  The  follouiing  selections  ond  ossignments  will  be 
mode. 

(1)  Eight  to  ten  questions  will  be  selected  ond  prioritized  from  QI 
(highest)  to  Q10  (lowest). 

(2)  fl  questlonHeoder  will  be  assigned  to  each  question.  The. 
principol  role  of  eoch  question  tender  is  to  stand  up  and  lead  the 
discussion  for  their  assigned  question. 

(3)  R  back-up  to  the  question-leader  will  be  assigned  for  each 
question.  The  principal  role  of  each  back-up  is  to  act  as  a  scribe  to 
capture  the  discussion  content. 

The  schedule  for  Session  I  is  as  follows: 

Getting  Organized  30  minutes  2:00-2:30 

-Agenda  Discussion 
-Question  Selection 
-Question  leader,  Sock -up  Assignment 


Brainstormnig 

QI 

20  minutes 

2:30-2:50 

02- 

20  minutes 

2J50-3:I0 

Q3 

1 5  minutes 

3:10-3:25 

Break 

10  minutes 

3:25-3:35 

Brainstorming 

Q4 

1 0  minutes 

3:35-3:45 

QS 

f  0  minutes 

3:45-3:55 

Q6 

20  minutes 

3:55-4:15 

Q7 

20  minutes 

4:15-4:35 

BoiewmSint  • 
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Break 

5  minutes 

4:35-4:40 

Brainstorming 

Q8 

1 5  minutes 

4:40-4:55 

Q9 

IS  minutes 

4:55-5:10 

QtO 

I Q  minutes 

5:10-5:20 

Reciama  any  Question 

1 0  minutes 

5:20-5:30 

Ouling  Session  i  or  immediately  folloiuing  session  t  eacti  questionHeader  ' 
and  ttielr  oactc'up  tuill  prepare  one  or  tuio  uugrapns  summanzing  the 
content  of  eacn  brainstorming  response  to  the  questions.  These  uugraplir 
luili  be  needed  for  Session  ii  and  the  final  report. 
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Session  Ut  IDcdnesdau  1:50-5:30 

Each  question-leader  with  the  help  of  his  bacic-up,  will  haue  prepared  ona 
or  two  uuqraphs  summarizing  the  most  interesting  preuious  day^s 
brainstorms.  The  assigned  question-leader  and  back-up  for  Session  i  will 
euchange  roles  for  Session  ii. 

fls  in  Session  i  each  question  will  be  addressed  one  at  a  time.  The  goal  of 
this  second  pass  is  to  sharpen  the  focus  on  each  question  and  to  list 
recommended  actions  as  though  we  were  omniscient  and  ali-powerful. 
Our  answers  to  each  question  should  take  the  form  of: 


lUhat?  i.e.  Features 

Uihy?  i.e.  Benefits 

How?  i.e.  Actions 

The  schedule  for  Session  il  is  as  follows: 

Benefits,  Features,  Actions 

Q1 

25  minutes 

1:30-1:55 

Q2 

25  minutes 

1:55-2:20 

Q3 

20  minutes 

2:20-2:40 

04 

15  minutes 

2:40-2:55 

Break 

1 0  minutes 

2:55-3:05 

Benefits,  Features,  Bctionr 

OS- 

10  minutes 

3:05-3:15 

06 

25  minutes 

3:15-3:40 

07 

25  minutes 

3:40-4:05 

08 

20  minutes 

4:05-4:25 

Break 

5  minutes 

4:25-4:30 

Benefits.  Features,  Actions 

09 

1 5  minutes 

4:30-4:45 

OlO 

15  minutes 

4:45-5:00 
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Rectama  any  Qestion  20  minutes  5:00*5:20 

UJrltlng  assignments  and 
redrafting  document 

outline  1 0  minutes  5:20*5:30 

Qurlng  Session  ii  or  soon  after  the  question*ieader  and  their  hacic*ud  mill 
prepare  one  or  tuio  uugrapns  summanzing  the  ansuiers  in  a  features; 
benefits,  actions  format. 
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fl  third  session  in  the  euening  mill  be  required  to  complete  our  lurite-ups; 
Ourlnq  the  last  ten  minutes  of  Session  tl  turitinq  assignments  mill  haue 
been  made. 

The  primarg  task  mill  be  for  each  queston-ieader  and  back-up  to  lurtte 
facing  page  tent  to  the  tu/o  to  four  uugraphs  created  in  Sessions  1  and  II. 
Each  participant  can  eupect  to  be  inuolued  luith  luritlng-up  tmo  questions 
plus  mriting-up  one  more  brief  section. 

The  tentatiue  outline  for  our  tUorking  Group  3  document  Is  as  foiloms! 

document  Outunp 

t .  Ulorking  Group  3  Format 

-uforking  group  methodology 

-setting 

-participants 

Prototyping  and  knomlege-based  approaches 
for  requirements  engineering: 

Problem  statement 

3.  -  Summary 

Short  rerm  Technical  Prospects 

3.2  Longer  Term  Technical  Prospects 

3.3  Changes  in  the  Softuiare  Oeueiopment  Process 

Model 

3.4  Technical  Transfer  Prospects 

3.5  Supporting  ftesearch 

3.6  Special  Problems 
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4.0  Question  summon} 

4.1  Q1  >  uugrapns  plus  facing  page  tent 

4.2  Q2 

t 

4.10  Q1Q 

S.  flppendlH  Material 

TPis  document  outline  mill  be  redrafted*  if  necessarg,  at  the  end  of  Session 
II. 
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JOINT  DECLARATION 
U.S.  President  &  British  Prime  Minister 


TKS 

Tsscaaoem 

ClDSI^Ci^aJIKiCO 

PEXESOai!) 


Oct.  25.  1957 


"The  arrangement  which  the  nations  of  the  free  world  have 
made  for  collective  defense  and  mutual  help  are  based  on 
the  recognition  that  the  concept  of  national  self- 
sufficiency  is  now  out  of  date.  The  countries  of  the  free 
world  are  interdependent  and  only  in  genuine  partnership, 
by  combining  their  resources  and  sharing  tasks  in  many 
fields,  can  progress  and  safety  be  found.  For  our  part  we 
have  agreed  that  our  two  countries  will  henceforth  act  in 
accordance  with  this  principle.* 

•  TRIPARTITE  TECHNICAL  COOPERATION  PROGRAM 

Canada  joined  U.S.  &  U.K.  immediately 

•  THE  TECHNICAL  COOPERATION  PROGRAM 

Australia  -  July  1965 

New  Zealand  -  October  1969 


Tcca 

TQdtxnsa 
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TTCP  AIMS 


•  PROVIDE  KNOWLEDGE  &  INFORMATION  ON 

EACH  OTHERS  PROGRAMS 

•  AVOID  UNNECESSARY  DUPLICATION 

AMONG  PARTICIPANTS 

•  PROMOTE  CONCERTED  JOINT  EFFORTS 

TO  CLOSE  GAPS 

ENCOMPASSING 

-  BASIC  RESEARCH 

-  EXPLORATORY  DEVELOPMENT 

-  DEMOS  OF  ADVANCED  TECH  DEVELOPMENT 
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TECHNOLOGY  AREAS 


TCSS 

TfiiaiiianflfflA. 

pa)®@ai&i23 


SUBGROUPS 

•  Chemical  Defense  •  Undersea  Warfare 

•  Aeronautics  Technology  •  Infrared  &  ElectroOptical 

Technology 

•  Radar  Technology  •  Materials 

•  Electronic  Warfare  •  Communications  Technology 

&  Information  Systems 

•  Behavioral  Sciences  •  Conventional  Weapons 

Technology 

•  COMPUTING  TECHNOLOGY 
PANELS;  ACTION  GROUPS;  TECH  LIAISON  GROUPS 


Tcca 

TQOCOUDSIflO. 

pQsaaiaia 


COMPUTING  TECHNOLOGIES 
SUBGROUP  X  (SGX) 


TECHNICAL  PANELS 

XTP1  -  Trustworthy  Computing 

XTP2  -  Software  Engineering 

XTP3  -  Architectures 

XTP4  -  Machine  Intelligence 

ACTION  GROUPS 

XAG2  -  Digital  Design 

XAG3  -  Image  Information 
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XTP2  -  SOFTWARE  ENGINEERING 


Tcoa 

TBSCXaOSat 

c@a$6a!£anKMi> 


PURPOSE:  To  improve  the  utilization  of  the  collective 
resources  and  capacities  of  the  member 
countries  in  the  areas  of  software  engineering 
and  software  technology. 


SCOPE:  The  creation  and  life-cycle  support  of  software 

•  for  military  applications. 

Includes:  PROCESSES,  METHODS,  TOOLS  for 

DEFINITION  SPECIFICATION  PROTOTYPING 

DESIGN  INTEGRATION  TEST 

EVALUATION  PORTING  REUSE 

DATABASE  TECHNOLOGY 


Toa 

Ta®coiai@a(t 

csxiaQaiffimew 
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XTP2  -  WORKSHOPS 


.  REAL  TIME  SYSTEMS  AND  ADA 

Conducted  June  1988,  at  IDA,  Washington  DC. 
Approx.  40  participants. 

.  REQUIREMENTS  ENGINEERING/RAPID  PROTOTYPING 
Planned  for  November  1989,  at  Fort  Monmouth 
(Eatontown),  NJ. 

-  SOFTWARE  METRICS 
Planned  in  1990. 
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TTCP 

XTP2  TASK 


AIMS 

•  To  examine  the  current  state  of  methods  and 

tools  used  for  requirements  engineering 

•  To'  identify  their  deficiencies 

•  To  recommend  new  or  improved  methods  and 

tools  that  need  to  be  developed 
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Technical  Presentation  1 


"The  Nature  of  Requirements" 


Mr.  James  Toher 
Pembroke  House,  United  Kingdom 


Overview 


^  Assignments 

Consultancy,  Training  &  R&D 
Large  &  Complex  Systems 
Industry,  Military  &  Govt 

^  Issues 

N on~F unctional  Requirements 

Validation 

Politics 


Requirements 


^  Functional  +  *Non-Fiinctional 
All  Interact 
^  NF  Dominates  F 


Functional  Requirements 


O  The  rate  of  decelaration  will  be  calculated, 
displayed  to  the  driver  who  will  compare  it 
with  the  reference  speed. 

O  On  supply  of  retailer  identification  the 
authorisation  number  will  be  derived. 


O  ForAll  e  memberof(HCL) 

Exists  r  memberof(Verf-Rec) 
and  r  =  PF(e) 

O  Automatic  dialling  of  previously  stored 
numbers  by  pressing  a  single  key 


Non-Functional 

Reliabilty 

Materiality 

Criticality 

Safety 

Security 

Vulnerability 

Performance 

Risk 

Repairability 

Timing 

Accuracy 

Timeliness 

Survivability 

Confusion 

Confidentiality 

Maintainability 

Cost 

Tolerance 

Transportability 

Precision 

Capacity 

Speed 

Ownership 

Manning 

Quality  of  Service 

Interoperability 

Traceability 

Size 

Usability 

Latency 

Media 

Compatibility 

Currency 
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Non-Functional  Requirements 


O  After  the  Final  Agreement  and  before  11.00  a.m 
the  Clearing  Totals  must  be  entered  on  the  Daily 
Settlement  Sheet.  (Timing) 

O  The  application  must  cope  with  50  million 
different  air  fares.  (Capacity) 

O  When  Central  Control  fails  Local  Control  must 
order  signals  (no  priority)  (Survivability) 

O  Authorisation  must  be  available  100%  between 
Mon-Fri  (inc)  during  hours  8.00  a.m-S. 00p.m. 
(Availability) 

O  Billing  must  conform  to  level  H2  with  category 
D3  (External:  collusive/ manipulative). 
(Vulnerability  to  Fraud) 


Interactions 


O  Limit  functions  available  to  alleviate  capacity 
overload  and  therefore  degradation  of 
performance.  NF  ->  F 

O  Increase  in  services  available  increase 
confusion  of  driver  and  decreases  safety 
F  ->  NF 

O  Increase  in  security  encourages  more  usage 
and  increases  congestion. 

NF  ->  NF 
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Problems 


O  NF  addressed  too  late  (if  at  all) 

Hidden  Complexity 
Loss  of  Control 

O  Methods 

First  Class  Treatment  of  NF 
True  Systems  Methods 

^  Prototyping 

Exhibiting  NF  Properties 
Reasoning  about  Interactions 


'Correct'  Requirements 

O  Validation  Principle  &  Guarantor 

O  Principle 

Output  •  Outcome 
Behaviour  -  Effect 

o  Guarantor 

Many  Stakeholders 

O  Validation  Statements 

Proof  -  Weak  Inference 


D-11 


Principle 


Signed  off  and  accepted 
In  use  for  several  years 
Happy  user 
Not  failed  yet 


The  system  is  always  the  servant 
of  the  'business*  and  its  needs 


Is  it  Effective  w.r.t  its  Guarantor 


Behaviour  ->  Effect 


KREA  TRAFFIC  CONTROL 


mprovf  road  taftty 

rtiuct  rnriroHmtatal  dtgradation 

assist  public  strriets 

provide  information  to  road-users  and  other  systems 
provide  economic  benefits  to  the  community  as  a  whole 


ELECTRONIC  POINT  OF  SALE 


increase  throughput 
guaranteed  pricing 
extra  sales  floor  area 
improved  tokest  handling 
reduce  fraud 

reduce  central  cash  administartion 


AUTOMATED  TICKET  BARRIERS 


reduce  fraud 

improve  traffic  information 

reduce  staff  costs 

permit  flexible  price  structure 
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Guarantor 


User 

General  Public 

Customer 

Suppliers 

Sponsor 

Beneficiaries 

Maintainers 

Victims 

Employees 

Managers 

Operators 

Regulators 

Problems 

O 

Legitamacy 

O 

Credibility 

o 

Methods 

Behaviour!  Outcome 

o 

Prototyping 

Demonstration 

Universal  Generalisations 
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Politics  &  Culture 

o  Meta-Systems 
^  Every  Situation 

Three  systems  are  present 

O  Every  System 

Changes  the  structures 

^  Every  Problem  —  Solution 

Requires  the  three  elements 


Every  Situation 

o 

Production  Systems 

o 

Belief  Systems 

o 

Political  Systems 
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Every  System  . 

^  Can  have  a  long  timeframe 

Affects  most  or  all  of  the  organisation 
Involves  substantial  resources 
Has  the  potential  to  lead  to  major  changes. 
Has  winners  and  losers 

^  Influences  the  political  and  cultural  systems 


Cultural  Effects 

o 

Increased  alienation 

o 

Changes  in  status 

o 

Social  isolation 

o 

Challenge  to  values 
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Political  Effects 

o 

SHIfls  in  baiuut  of  powtr 

O 

Heirarchitt  may  chongt 

o 

Job  lotut 

o 

Working  rtlatiomhipi  my  bt  ttrointi 

o 

Span  of  control  shifit 

o 

Sytttmi  of  groiing,  promotion, 

rtwori  may  btcoma  rtiuniant  j 

o 

Shifting  probUmi/thrtolt 

o 

Demarcation  ittuat  may  alter 

o 

Intimity  of  worUmoehini  pacing 

o 

Threat!  to  confidentiaiity 

o 

Poioritotion 

o 

Hiirarchiee  may  change 

Every  Problem  —  Solution 


O  Requires  an  understanding  of  the  three  elements 


Problem 


Solution 
P  C  T 

P  PI  \j 

C 

T  J 
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Technical  Presentation  2 


"The  Role  of  Requirements 
in  the  System  Development  Process" 


Mr,  Edward  H.  Schlosser 
Lockheed  Software  Technology  Center,  USA 


Old  Approach:  Allocate  System  Requirements 
Between  Hardware  and  Software  Up  Front 


REQUIREMB^ 

TREE" 


So({w*r*  T>dwo<P9y  C«m*r 


Don't  Break  Out  System  Requirements  into 
Hardware  and  Software  Requirements  Up  Front 


Why? 


W«  lick  ditiilid  knowlidgi  up  Iront  to  maki 
good  dicisions  about  allocating  requiraments 
to  hardware  or  software. 


A  reasonable  allocation  to  hardware  or  soft¬ 
ware  may  become  inappropriate  later  due  to 
changes  in  needs  &  available  technology. 


All-or-nothing  allocation  of  a  requiremsnt  to 
hardware  or  software  is  often  unrealistic. 


All-or-nothing  allocation  may  limit  or 
prevent  exploitation  of  complementary 
hardware  and  software  capabilities. 


Lockheed 

S  SpaC9  Company^  Inc, 

rKfiftOogy 
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Hardware/Software  Differences  Are  Complementary 


Hardware  wears  out  &  breaks. 

Software  does  not  wear  out  or  oreaK. 

Hardware  gets  out  of  adjustment  or  calibration. 

Software  does  not  get  out  of  adjustment  or 
calibration. 

Hardware  runs  fast. 

Software  runs  slow. 

Manufacturability  of  hardware  is  limited  by  its 

Reproducability  of  software  is  not 

complexity  and  by  the  laws  of  physics  & 

significantly  limited  by  its  complexity  or  by 

chemistry. 

the  laws  of  physics  &  chemistry. 

Hardware  is  often  difficult  to  install  t 

Software  can  be  made  largely  self-installing  & 

configure. 

self-configuring. 

Retrofitting  &  upgrading  hardware  is  often 

Retrofitting  &  upgrading  software  can  be 

difficult. 

highly  automated. 

User  assistance  and  training  cannot  be  built 

User  assistance  &  training  can  be  built  into 

into  hardware. 

software. 

Lockheed 

1  Spac9  Companyt  ine, 

Softww*  rMivwogy C«Ai*r 


Hardware/Software  Cost  Differences 
Are  Complementary 


Developing  the  first  copy  of  hardware  is 
costly. 

■ 

Developing  the  first  copy  of  software  is  also 
costly. 

Hardware  is  difficult  and  costly  to 

Software  is  easy  and  cheap  to  reproduce  with 

manufacture  to  orecise  tolerances. 

precise  dioital  fidelity. 

Developing  special  tooling  and  processes  to 
manufacture  hardware  is  costly. 

Standard  tooling  and  processes  can  be  used  to 
repticate  software. 

Hardware  design  changes  often  require  costly 
changes  in  tooling  &  manufacturing  processes. 

Software  design  changes  usually  do  not  require 
changes  in  tooling  and  processes  used  to 
replicate  software. 

It  is  difficult  &  costly  to  make  hardware 
self-diagnosing. 

It  is  easier  &  less  costly  to  make  software 
self-diagnosing. 

The  large  costs  of  tooling  for  hardware 
manufacturing  have  encouraged  application 
independence,  standardized  interfaces  &  reuse. 

The  minimal  costs  of  tooling  for  software 
replication  have  discouraged  application 
independence,  standardized  interfaces  &  reuse. 

Lockheed 

MIssilaa  Si  Spaea  Companyf  Inc. 

So(^<*art  r*cnnoiD^C«<u*r  *23 
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Benefits  from  Exploiting  Complementary 
Characteristics  of  Hardware  and  Software 


Components  that  exploit  the  complementary  capabilities  of  hardware  and 
software  internally  can  provide  greater  capabilities  at  less  cost  than 
all'hardware  or  all-software  components.  Such  mixed  hardware/software 
components  should  have  the  following  desirabie  properties: 


Early  warning  of  failure 
Self-adjusting  &  self-calibrating 
Both  fast  &  customizable 
Self-installing  &  self-configuring 
Self-checking  &  seif-diagnosing 
Automated  support  for  retrofitting 


•  Built-in  user  assistance  &  training 

•  Less  costly  initial  tooling 

•  Less  costly  retooling  as  component 

is  improved 

•  Fewer  &  less  costly  repairs 

•  Improved  standardization  &  reuse 


Lockheed 

MisailBS  S  SpacB  Company,  Inc. 
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Don't  Break  Out  System  Requirements  into 
Hardware  and  Software  Requirements  Up  Front 


Why? 

What  should  wa  do? 

Defer  allocating  requirements  to 

We  lack  detailed  knowledge  up  front  to  make 
good  decisiona  about  allocating  requirements 
to  hardware  or  software. 

hardware  or  software  until  lower 
levels  ot  design  when  we  know  more. 

Allocate  requirements  up  front  to 
system  components  likely  to  contain 
both  hardware  &  software. 

A  reasonable  allocation  to  hardware  or  soft¬ 
ware  may  become  Inapproprlete  later  due  to 
changes  in  needs  &  available  technology. 

Encapsulate  allocations  within  low- 
level  system  components  so  they  can 
be  changed  without  "rippling." 

All-or-nothing  allocation  ot  a  requirement  to 
hardware  or  software  Is  often  unrealistic. 

Allocate  functions  which  support  the 
requirement,  some  to  hardware  and 
some  to  software,  as  appropriate. 

All-or-nothing  allocation  may  limit  or 
prevent  exploitation  of  complementary 
hardware  and  software  capabilities. 

Share  responalbllity  tor  a  low-level 
function  between  hardware  A  soft¬ 
ware  when  they  are  complementary. 

Lockheed 

Mlssltas  A  Spaca  Company,  Inc. 

ScnwM*  T«cftnoi09V  C«nt«r  *23 
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New  Approach:  Allocate  Functions  Between 
Hardware  and  Software  at  Lower  Levels  of  Design 


REQUIREMENTS  -TREF  DESIGN  -TREF 


Lockheed 

A  Spae»  Company,  tne. 

Sonwv*  T»a>noc9v  C4fiw 


Benefits  from  the  New  Approach 


•  Minimize  risk  of  bad  hardware/software  allocation  due  to  limited  information 


•  Minimize  "ripple"  effect  of  changes  in  requirements  and  technology 


•  Avoid  arbitrary  "all'Or>nothing"  allocation  to  hardware  or  software 


•  Exploit  complementary  capabilities  of  hardware  and  software 


Lockheed 

Mlaallaa  A  Spaca  Company,  Inc. 

Sonww*  T•c^no09vC4n1•f 
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Technical  Presentation  3 


"Overview  of  Rapid  Prototyping  Systems" 


Mr,  Scott  P,  Overmyer 
Contel  Technology  Center,  USA 


A  Rapid  Prototyping  Tooi  is  . . . 

A  tool,  or  set  of  tools  which  allow  user-computer  interface 
designers  to  QUICKLY  and  INEXPENSIVELY  construct  a  high 
fidelity  simulation  of  an  interactive  system.  To  be  effective,  a 
rapid  prototype  must  not  only  convey  the  look,  but  also  the  feel  of 
a  proposed  system  design  to  users,  customers,  and  developers. 


wxm 


C^=5=^ga  TecJineiogy 
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Goais  of  Rapid  Prototyping 

•  Determine  user  requirements 

•  Communicate  the  design 

•  Exercise  the  design 

•  Collect  human  and  system  performance  data 

•  Evaluate  the  design 

•  Market  the  design 


RAPC03 
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i  Center 


Tasks  in  Rapid  Prototyping 

•  Design  and  develop  screen  layouts 

•  Select,  design  and  develop  dialog  method 

•  Implement  applications  (in  some  form) 

•  Link  screens,  applications  and  dialog 

•  Make  rapid  iterations  on  simulation 

•  Collect  and  analyse  user  and  system  performance  data 


RAPC^ 


Products  of  Rapid  Prototyping 

•  "Live"  user  requirements  specification 

•  Human-computer  interface  design 

-  Dialog  concept 

-  H-C  task  allocation 

-  I/O  control  concept 

-  System  and  user  response  time  requirements 

•  CDRL  figures  (screen  print/plots) 

•  Quantitative  and  qualitative  requirements  validation  criteria 


RAPfOOS 
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Transition  to  the  Operational  System 

•  Throwaway  rapid  prototyping 

-  Brief  final  version  of  prototype  and  specs. 

-  Deliver  prototype  and  specs  to  developers 

-  Monitor  code  and  unit  test 

-  Compare  operation  of  prototype  to  that  of  operational 
modules  during  integration  and  test 

•  Evolutionary  prototyping 

-  Generate  user-interface  management  software 
from  prototyping  tool  -or-  Use  prototype  code 

-  Integrate  application  modules 

-  Make  it  all  work  together  (e.g.,  compile  and  run) 


RAPCOt 


General  Rapid  Prototyping  Tool  Req'ts 

•  Foster  RAPID  prototype  development 

-  Coding  is  usuallytoo  slow 

•  Allow  non-programmers  to  learn  and  use 

•  Allow  end-user  interaction 

-  Pictures  alone  do  not  provide  "feel" 

•  Allow  integration  of  external  applications 

•  Provide  automated  system  and  user  performance  data 
collection 

•  Help  with  generation  of  CDRLs 

-  ICD’s,  HEDAD-p,  HEPP,  HEPR 

RAPOOT 
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Specific  Rapid  Prototyping  Tool  Req'ts 

Screen  Development 

•  Alphanumerics  (text)  display 

•  Graphics  display 

-  drawing/painting  package 

•  Cursor  or  command-oriented  screen  construction 

•  Windowing 

-  tiled  (e.g.,  standard  viewports) 

-  overlapping  (e.g.,  X  Windows) 

•  "Object"  creation/definition 


RAPCM 


Specific  Rapid  Prototyping  Tool  Req'ts 

Dialogue  Development 

•  Menus 

-  Static,  dynamic 

-  Pull-down,  pop-up,  slug 

•  Forms 

-  Tab  back  and  forth  between  fields 

-  Range  and  value  checking  for  fields 

•  Command  language  (string  parsing) 

•  Icons  (direct  manipulation) 

-  Objects,  graphics,  sliders,  buttons,  dials,  knobs 

•  Voice  I/O 

RAP1D09 
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Specific  Rapid  Prototyping  Tooi  Req'ts 

Hardware  and  Device  Support 

•  input  device  handiing 

-  Cursor  controi 

-  mouse,  tabiet,  cursor  keys,  joystick,  trackbail 

-  Voice 

-  Gesture,  eye  motion 

•  Output  device  handiing 

-  Monochromatic  dispiays  . 

-  Color  displays 

-  High  and  low  resolution  dispiays 

-  Auditory  displays 

-  tone  generation 

-  voice  synthesis 

-  Virtual  environment  dispiays  (e.g.,  Eyephones®) 


Specific  Rapid  Prototyping  Tooi  Req'ts 

Database  Capability 

•  Forms  processing 

-  Data  entry 

-  Data  retrieval 

•  String  storage 

-  Command 

-  Value  (variable) 

-  Current  state 

•  Help 

-  Context  dependent 

-  Context  free 

•  General  data  retrieval  n 
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Specific  Rapid  Prototyping  Tooi  Req'ts 

integrated  Application  Support  (for  C3I  prototyping) 

•  Geographic  projection  and  display 

-  Vector,  raster,  video 

-  Geographic  overlay  capability 

-  Line  and  symbol  display  and  manipulation 

-  Lat/Long-based  calculations 

-  course,  distance,  trajectory 

-  zoom  and  pan 

-  satellite  ground  trace  and/or  orbit 

•  Graphs  &  plots 

•  Time-based  simulation 

•  Image  display  &  manipulation 

RAPIOta 


Specific  Rapid  Prototyping  Tool  Req'ts 

Display  and  Dialogue  Linkage 

•  State  transition  based  linkage 

-  Link  menu  options  to  actions  or  "applications" 

-  Link  objects  to  actions 

-  Link  menu  options  or  objects  to  displays 

-  Link  time  or  events  to  actions 

•  Command  parsing  and  linkage  to  actions 

•  Sequence  execution 

•  Possible  code  generation,  if  available 


RAP1013 
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Specific  Rapid  Prototyping  Tooi  Req'ts 

Automated  Data  Collection 

•  Keystroke  recording  and  timestamp 

•  Error  data 

-  Error  type 

-  Error  frequency 

•  Task/thread  data 

•  User  comments 

•  Sequence  recording  and  playback 

•  Configuration  management  and  iteration  control 

RAPnU 

Technology 
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My  Current  Toolbox 


•  Skylights  GX 

-  IBM  PC  or  compatible 

-  VGA  graphics 

-  Elographics  touch  screen 

-  Dragon  Systems  Dragonwriter  1 000  VR  Board 

-  Microsoft  Bus  Mouse 

•  Dan  Bricklin's  Demo  I! 

-  IBM  PC  or  compatible 

-  Color,  but  alphanumeric 

•  TAE  Pius 

-UNIX  (SUN  3/160) 

-  X  Windows-based 

-  High-res  color  graphics 

RAPIOIS 
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My  Current  Toolbox  -  Part  2 

•  VideoWorks  Interactive 

-  Macintosh  SE  or  Macintosh  II 

-  High-res  color  graphics 

•  HyperCard 

-  Macintosh  SE 

-  Monochrome 

•  SuperCard 

-  Macintosh  SE  or  Macintosh  II 

-  HyperCard  compatible 

-  Color 

-  Full-screen  capabilities 

•  Various  &  sundry  programming  languages 

-  C,  PASCAL,  (even  ADA) 


Tool  Features  Matrix 


Skylights  GX 

DB  Demo  11 

TAE  Plus  4.0 

VW  Interactive 

HyperCard 

Supercard 

Graphics 

X 

X 

X 

X 

X 

Windowing 

X 

LTD 

X 

X 

X 

Object  Definition 

LTD 

LTD 

LTD 

Manus 

X 

X 

X 

X 

X 

X 

Forms 

X 

X 

X 

X 

Command  Parsing 

X 

LTD 

Icons  and  Symbols 

X 

Color 

X 

X 

X 

X 

X 

DBMS 

LTD 

LTD 

LTD 

LTD 

Applications 

DRAW 

DRAW 

DRAW 

DRAW 

User  Interactive 

X 

X 

X 

X 

X 

System  Generation 

X 

X 

X 

X 

X 

Data  Collection 

fW>l017 
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Editorial  and  Summary 

•  To  perform  effective  RAPID  prototyping: 

-  Must  be  able  to  build  and  modify  quickly 

-  Tool  kit  is  essential 

-  Must  present  both  look  and  feel 

•  Rapid  prototyping  is  not  a  panacea 

•  Throwaway  prototyping  is  worth  doing 

-  Validated  requirements 

-  Human  engineered  user-computer  interface 

•  The  "right"  rapid  prototyping  tool  has  not  yet  been 
built 

-  A  multiple  tool  toolkit  is  best  bet 

-  New  tool  development  may  be  money  well  spent 

-  Acquire  existing  tool,  and  add  on  (good  strategy) 

RAFfOtl 
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Technical  Presentation  4 


"A  Possible  View  of  Requirements  Engineering" 


Dr.  Winston  W.  Royce 
SoftwareFirst,  USA 


A  POSSIBLE  FUTURE  VIEW  OF  REQUIREMENTS  ENGINEERING 


•  Life  Cycle  Process 

•  Requirements  Engineering  Phase 

•  The  Production  Artifacts  Problem 

•  The  Manager  vs.  Software  Designer  Problem 

•  The  Communications  Problem 


LIFECYCLE  PROCESS 


LIFE  CYCLE  PROCESS 


a 


/ 

Operational 

/ 

HI 

A 

Validation 

(=  1  year) 


•  Under  Control  Of  Using  (And  Logistics)  Command 

•  Validation  Of  Products 

•  User  Achieves  Confidence  As  Though  They  Built  It 

•  Continuous  (Small  Scale)  Change  Process 


r 


LIFE  CYCLE  PROCESS 


Software 

IHi 

1  Operational  | 

HBj 

Manufacturing 

■1 

1  Validation  | 

(=■3/4  year) 


(=  1  year) 


•  Temporary  Requirements  Freeze 

•  Selection  Of  Computer  Hardware 

•  Optimization  Of  Performance;  Use  Of  Efficient  Procedural  Language 

•  Concern  For  Correctness 

•  Very  Short  Schedule 

•  Fixed  Price;  Warrantied;  Possibly  Competitive 

•  Modest  Up-front  Investment  For  Tools  And  SDE's;  SDE  Can  Be  Closed 
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(  LIFE  CYCLE  PROCESS 


a 


Requirements 

hr 

Software 

■■ 

Operational 

Engineering 

Hi 

,  Manufacturing 

■K 

Validation 

(srlVj  years)  (=-3/4  year)  (=  1  year) 


•  Requirements  Changes  Are  Encouraged 

•  Software  Design  Independent  Of  Computing  Platform 

•  Highly  Automated  Coding;  Declarative  VHLL; 

Enormous  Productivity 

•  Abstraction  Oriented  In  All  Things 

•  Prototyping;  Reuse;  Simulation 

•  Trial  Deliveries  Into  The  Field 

•  Evaluation  Of  Multi-competing  Designs 

•  Cost  Plus;  Always  Competitive 

•  Large  Up-front  Investment  For  Tools,  SDE's; 

SDE  Must  Be  Open 


THE  PRODUCTION  ARTIFACTS  PROBLEM 


REQUIREMENTS  PHASE 


THE  MANAGER  VS.  SOFTWARE  DESIGNER  PROBLEM 


System  Processing  Harness 

•  System  Communications 

•  System  Control 

•  System  Data  Handling 


THE  MANAGER  VS.  SOFTWARE  DESIGNER  PROBLEM 


System  Processing  Harness 

•  System  Communications 

•  System  Control 

•  System  Data  Handling 


THE  MANAGER  VS.  SOFTWARE  DESIGNER  PROBLEM 


Requirements  Spec 
Phenomenology  Spec 
Glueware  Spec 
User  Interface  Spec 


QA  CM  PM 

III 


Executable  Spec 

Prototype 

Documents 


This  page  is  intentionally  left  blank. 
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Technical  Presentation  5 


"Multiple  Views  of  Requirements" 


Dr.  Alan  M.  Davis 
George  Mason  University,  USA 


CLASSIC  DEFINITION  OF  REQUIREMENTS 


The  activity  that  encompasses  the  definition  of  “what"  the  system  is 
without  decribing  “how"  it  works. 


BETTER  DEFINITION  OF  REQUIREMENTS 


0  All  activities  up  to  and  including  the  definition  of  the  system's 
external  behavior 

o  It  thus  includes  analysis  of  the  problem  domain  which  clearly 
precedes  external  behavior  specification  of  the  solution  system 

o  It  thus  excludes  definition  of  any  of  the  actual  physical  sub¬ 
components  of  the  system  under  specification 

o  Note:  External  behavior  can  be  described  at  any  level  of  detail  and 
it  is  still  requirements 
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MULTIPLE  DIMENSIONS  OF  REQUIREMENTS 


o  Problem  Analysis  vs.  External  Behavior  of  Solution  System 
0  Levels  of  Abstraction 
o  Multiple  Views 


ANALYZING  PROBLEMS  OR  SOLUTIONS? 


•  What  is  the  problem,  not  how  are  we  going  to  solve  it 

•  Primarily  decomposition  process 

-  Ambiguity/fuzziness 

•  Purely  in  terms  of  problem  owners 

•  What  is  the  solution  system,  not  how  will  it  work  internally 

•  Primarily  a  descriptive  (specification)  process 

•  Consistency 

<  Springboard  for  design  and  test 

-  Purely  in  terms  of  users 

•  Understanding  so  you  can  make  intelligent  choices  v.  external 
manifestation 

•  Problem  analysis  v.  documenting  external  behavior 

•  Both  included  in  requirements  phase 


Ccf^ight,  BTC,  Inc.,  1988 
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LEVEL  OF  REQUIREMENTS 
ABSTRACTION 


•  Communicate 

•  Communicate  via  voice 

•  Communicate  via  telephone  system 

•  Provide  local  calls,  call  forwarding,  long  distance 

•  To  make  a  long  distance  call 
'  Lift  phone 

-  Hear  dial  tone  within  2  seconds 

•  Dial  9 

•  Hear  distinctive  dial  tone  within  2  seconds . 

•  To  make  a  long  distance  cal) 

-  If  dial  tone  generator  available 

Then  hear  dial  tone  within  2  seconds  on  clock  A 
Else  hear  reorder  tone  within  2  seconds  on  clock  A 


BTC,  Inc.,  lygg 

EXAMPLES  OF  VIEWS 


0  Asynchronous  Processes/Objects 
o  Data  Structures 
o  Data  Flows 
o  Data  and  Control  Flows 
o  Finite  State  Machines 
o  Extended  Finite  State  Machines 
0  Petri  Nets 

0  Human/Machine  Interface 
o  Hybrid 
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SAMPLE  OF  RICHNESS:  DATA  FLOW  VIEW 


iOdA 


I  cvrrowtii  | 


SAMPLE  OF  RICHNESS:  ER  VIEW 


SAMPLE  OF  RICHNESS:  FSM  VIEW 


lnvftkt4  cotn/colA 


•  •UctUA(Mi)/ 


SAMPLE  OF  RICHNESS:  OBJECT  VIEW 


gl 

'  \ 
customtr 

flavor 

dispansa 

fill 

ctioos.  J 

deposits 

ssfecu 

T 


— 

f - \ 

vending 

coin 

ptrton 

value 

count 

fills 

returns 

adds 

J 

changes 
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SAMPLE  OF  RICHNESS:  DATA  STRUCTURES  VIEW 


sou  SELECTIONS (3) 

NAME 

PRICE 

MAEIMUN'COUNT 

CURRENTLY-AVAIIAaLE-COUNT 

COINS-ENTERZD 

NUMBER-OF-NICKELS 

NUMBER>OF-OIHES 

NiniBEX-OF-CUARTERS 

DATE-OF>LAST-R£CULAR-MAINTENANCE 


SAMPLE  OF  RICHNESS:  HMI  VIEW 


SELECTION  fl  —  COKE  CLASSIC - - 

SELECTION  12  —  DIET  PEPSI  — - > 

SELECTION  13  —  RC  COU - > 

PUSH 

COIN  RETURN - - 

PUSH 
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EXAMPLES  OF  TECHNIQUES 


Technlqut  Prob  Sol'n  Func  Asyn  Data  Data  - FSM _  En. 

Oom  Oom  tion  Proe  Strc  Flow  Maatr  Slava  stlm  Feat  tllv 
Objta  ' 


Lavalaor 
HMI  Abtt'ilon 


SRD  X 

PAISUy  X  X 

JSD  X 

OORA  X 

DaMareoSAX 
WardSA  X 

HatlaySA  X 

Vfdon  MSA  X 

USE  X 

Statamata  X 

REVS  X 

RLP  X 


X 

X  X 

X  X 
X  X 

X 

X  X  X 

X  XX 

XXX 

X  XXX 

X 


X 

X 

X 

X 

X 

X 

X 

X 


X 


1 

1 

1 

2 

N 

N 

N 

N 

1 

N 

N 

1 


HATLEY  VS.  WARD 


0  Both  Combine  DFDs  and  FSMs 
o  Both  Add  Control  Signals 
0  Completely  Different  Semantics 
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THE  RESEARCH  GOAL 


o  Enable  Developers  to  Each  Select  Optimal  Views  for  Their  Aspect 
of  the  System 

o  Check  Any  View  for  Internal  inconsistency,  incompleteness,  and 
Ambiguity 

o  Derive  Parts  of  One  View  From  Another 
o  Check  for  Consistency  Among  Views 

o  Transform  Views  Used  by  One  Methodology  into  Views  Used  by 
Others 

o  "Execute"  a  Subset  of  Views  While  Observing  Any  One  View 


THE  RESEARCH  APPROACH 


0  Fully  Understand  Multiple  View  Problem 

-  Define  Meta-Model 

-  Define  Views  in  Terms  of  the  Meta-Model 

-  Formally  Define  View  Ambiguity,  Inconsistency, 
incompleteness 

-  Formally  Define  Inconsistency  Between  Views 

-  Establish  Derivation  Capabilities 

o  Specify  Requirements  for  a  Requirements  Environment 

-  Use  Multiple  Views 

o  Construct  the  Requirements  Environment 

-  Database 

-  Single-View  Checkers 

-  Multiple  View  Consistency  Checkers 

-  Automatic  View  Generators 

-  The  Executors 
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THE  BEGINNINGS:  A  FIRST-DRAFT  META-MODEL 


o  Object-Based 

o  Standing  on  Goad’s  Shouiders(OOA) 
o  A  Few  Views  Have  Been  Partially  Defined 
•  Objects 

-  Structure 

-  Attributes 

-  Service  Names 

o  Semantics  (i.e.,  Service  Definitions)  Still  Weak 


SUMMARY 


o  Wide  Spectrum  of  Requirements  Tools/Techniques/Languages 
Available 

0  Each  Ideal  for  a  Particular  Aspect  of  a  Problem 

o  Currently  Little  Compatibility  Exists  Conceptually  or  Physically 

0  ERA  or  Object-Oriented  Meta-Models  Appear  to  Offer  Potential  for 
Common  Underlying  Representations 

o  Representation  of  a  Few  Views/Methodologies  Using  an  OOMM 
Underway 
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Technical  Presentation  6 


"An  Integrated  Approach 
to  Requirements  Engineering" 


Dr.  Raymond  T.  Yeh 
International  Software  Systems,  USA 


Uncertainty 

Volatility 

Ambiguity 

Inconsistency 

Incompleteness 

Infeasibility 

Incorrectness 

Insufficient  Communication 

Inherent  Complexity 

Lack  of  concerns  for  the  entire  life  cycle 


The  Basic  Framework 


Requirements  Process  is  Intertwined  with  System 
Creation  and  Evolution  Process 


RcUlivt 

Effort 


Sjrtitm  Ate 


3*Qgirtn‘«nts  ?rv»ieemini> 

Cettminiticft  tie. 


Areas  of  Support  for  Requirements  Enzineering 
Must  be  Considered  in  an  integrated  Manner 
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Generic  Questions  in  Reniiirement?; 
Deviaiion  Activities 


1.  What  is  the  purpose  of  this  activity? 

2.  What  information  is  needed? 

3.  Who  is  involved? 

4.  How  is  the  needed  information  obtained? 

5.  What  to  do  with  the  information? 

6.  What  form  or  languageshould  be  used  to  document  the 

new  information? 

7.  Decision  criteria  as  to  whether  to  proceed? 

S.  What  tools  should  be  used? 


Definitions  and  Roles 


Process  Model  a  model  which  enables  defining  a  specific 
process. 


Process:  a  set  of  activities  needed  for  a  aoal  or  purpose. 

and  the  criteria  in  deciding  the  sequencing  and 
duration  in  the  execution  of  those  activities. 
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System  Context: 
Cr^amzation/ntssion 
Goals: 


System 
Constraints 
Oroanizatienai  Goal 
Strjcturcs: 
Aitematives: 


A  Reauirements  Engineering  Process  Mocel 


Generic  ReQuirements_Prncess  Activities 

•  Context  Analysis 

•  Objective  Analysis 

•  Requirements  Determination 
(evaluate  alternatives) 

•  Requirements  Analysis 

•  Requirements  Synthesis 

•  Requirements  Validation 
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Methodoiogy 


Purgose; 


provide  systematic  plans  for  accomplishing 
goals  or  implementing  guiding  principles. 


Aonroaches/lssues: 

*  What  principles  guide  the  process? 
For  cxtmpit: 

•  Scptnuion  of  eononit 

•  Risk 

•  Control  compitatT 


What  are  the  methods  that  tell  you  how  to  implement 
the  principles? 

For  nainplc: 


ModoUne 

•  Conctpiuti  moddinf 

•  Opcnuonal  modciiag 
(prototrpingl 


Work  stninure  breakdown 

•  Simpuncation 

•  Abftnction 

•  Partiu'on 

•  Projection 


PgQcls: 


Purnase; 

•  Identify  generic  role-players  (participants  and 
stakeholders)  for  the  process:  e.g.,  users, 
buyers,  sellers,  developers 


Apprnachesdssues: 

•  What  are  role-player  needs,  i.e..  their  view  of 
an  ideal  system? 

•  What  are  role-player  responsibilities  for 
activities:  input,  communication,  feedback, 
judgement? 
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Language 


Provide  exoroiion  ind  communication  for  and  amon^ 
different  people  and  different  concerns. 


•  mulUpIc  lantuaees  for  different  major  concerns. 
dtsctpUaea.  and  stakenolders 

•  multiple  tnlerfacea 

•  undcrtnnf  commonalitr  to  support  data-sharina.  automated 
aid  of  comraumcation 

•  formal  lao(uatca  for  preciseness,  automated  cneckint 

•  more  widespread  use  for  enhanced  support  of 
inlormation  capture 


Automation  (Tools^ 


Purpose: 


Provide  automated  support  lor  engineering  and 
management  activities. 


Annroachesilssues: 

•  What  is/are  the  right  tooKs)  to  use? 

•  What  is  a  right  kind  ot  architecture 
(e.g.,  integration  platform  i? 

•  How  do  you  incorporate  tools  into  practice? 


D-56 


Management 


P'-Irppse: 


direct  and  insure  coordination  of  resources  and 
processes  to  accomplish  goals 


Approachfis/Issuesi 


•  planning  and  controlling  allocation  of  resources: 
financial,  human,  material,  information,  time; 

•  measuring,  monitoring,  and  controlling  quality: 
of  process,  product,  and  people; 

•  utilizing  real  project  data  for  planning; 

•  getting  the  users  involved 

•  be  concerned  with  the  entire  life  cycle  process 

•  getting  the  baseline  requirements 

•  use  incremental  commitment 

•  separate  the  concerns. 


Generic  Questions  Within  Each  Activity 


Example  •  Objective  Analysis 

1.  Purpose 

•  Why  do  they  want  this? 

•  Do  they  really  want  what  they  are  saying? 

To  make  sure  organizational  investments  (long 
term  goals)  are  not  shorthanded  by  the  short 
term  system  goals. 

2.  What  information  is  needed? 

•  What  problems  currently  exist  in  the  organization? 

(problems  can  be  seen  as  the  difference  between  a 
desired  value  and  the  actual  achieved  value  on 
one  or  more  objective  dimensions) 

•  Need  to  have  the  goal/constraints  structure! 
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Scope  01'  goals  as 
seen  by  top  management 


Top  management 


Scope  of  goals  as 
seen  bv  miaole 
management 

Scope  of  i 

goals  as  seen  / 
on  tne  / 
operational  /— i 
level  /  y 


Middle  management 
(divisions, 
.departments; 


Operational 

level 


scope  of  goals  as  finally 
agreeo  upon 


Definition  of  the  scope  of  the  analysis 


(iA4  onte<tiv«t,  }uw<tw<v  dcieramt 

iifri  an<J  «l  4'nt«tiv<t 

rr^cvif  fcut<4  taaitgrct  co'tuainii 

•'  l'  v'  I,  '  '''' 


Kolc/activiiy  rclaiioiisiiip  during  the  OHIIiCI'l  VLS  ANALYSIS  phase 
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Generic  Questions  Within  Each  Activity 


4.  How  to  get  the  needed  information? 

(what  methods  tt-  use?)  - 
Questionairus.  Interviews,  etc. 

5.  What  to  do  with  the  information? 

(what  methods,  should  be  used  to  analyze  the  information?) 


•  Sutic  analysis 

consistency,  completeness 

•  Dynamic  analysis 
animation  of  goal  diagram 
What  if  analysis. 

•  Verification 

•  Validation 


6.  What  form  or  language  should  be  used  to  document  the 
new  information 

7.  Decision  criteria  as  to  whether  to  proceed? 

8.  What  tools  should  be  used? 


•  graphical  drawing  tools 

•  simulation  models  of  applications 
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Example  of  a  Goal/Constraint  Diagram 
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Summary 


Use  integrated  approach  to  solve  problems: 

•  requirements  process  intertwines  with  system 
evolution  process 

*  integrate  different  areas  of  concern 
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Technical  Presentation  7 


"Knowledge-Based  Requirements  Assistant" 


Mr,  Douglas  A.  White 
Rome  Air  Development  Center,  USA 


The  Challenges  of  Air  Force  Software 


0  Computer  Software  Dominates  the  Functioning  of  Most  Military  Systems 
(AF  Studies  Board) 

o  Computer  Software  is  a  problem  in  7  out  of  10  troubled  systems. 

(AFSC/PLR  "Bold  Stroke"  Briefing) 

0  Cost  of  AF  Mission  Critical  Software  will  Increase  by  50%  by  1 995. 

(EIA  Defense  Electronics  Market  1 0  yr  forecast) 

o  Software  was  5%  of  AF  budget  in  1986.  will  be  10%  by  1990. 

(Software  Growth  &  Logistics,  AFALC/ERC) 

o  Demand  for  Software  is  growing  at  12%/yr;  Personnel  4%/yr:  Productivity  4%/yr 
(Boehm,  Martin) 

0  Maintenance  Accounts  for  60-90%  of  Software  Lifetime  Costs 
(Software  Growth  &  Logistics,  AFALC/ERC) 

0  Cost  of  Software  Maintenance  is  growing  by  26%/year 
(V.  Castor/ OUSD(R&DT)) 


KNOWLEDGE-BASED  SOFTWARE  ASSISTANT 

(KBSA) 


BASIS  FOR  A  NEW  SOFTWARE  PARADIGM  -  SHIFTING 
FROM  INFORMAL  PEOPLE-BASED  DEVELOPMENT  TO 
FORMALIZED  COMPUTER-ASSISTED  DEVELOPMENT 
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KBSA  DEVELOPMENT  PARADIGM 


CEC:SIONS 

AND 


o  Machine  is  "in  the  loop" 

0  All  lifecycle  activities  machine  mediated  and  supported 
0  "Corporate  Memory" 
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Requirements  Engineering 


Acquisition,  analysis,  and  communication  of  system  description. 


System  Behavior 
Boundary  Conditions 
Trade-off  Formulas 
Dependencies 
Definitions 


TODAYS  TECHNOLOGY 
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o  o 


FORMAL  REQUIREMENTS 
(SOCLE) 


Ex.  Constraint: 

{air-traffic-control  (ako  ($value  (system))) 

(constraint  ($vaiue  ((multiplier  (at*  tracker  initiation  time) 

(at*  objects-tracked  speed) 

(at*  geographic-coverage  distance)))) 


Ex.  Formula: 


(multiplier  (at  radar-43  sweep-rate) 

(at  tracker-21  number-of-radar-returns-required) 
(at  tracker-21  initiation-time)) 


KBRA  THEME 


Incremental  Formalization  o  Reusable  Programming  Knowledge 

Presentation  Based  Interface  o  Trade-off  Analysis  Support 
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BENEFITS 


Informal  - 

Multiple  views,  no  formal  computer  language,  postpone 
commitments 

Consistent  - 

Single  knowledge  representation  with  automated 
reasoning  and  truth  maintenance 

Incremental  - 

"Catch-as-catch-can”  interpretation,  associative 
retrieval,  critiquing,  automatic  completion 

Reusable  - 

Libraries  of  application  knowledge 

KBRA  Control  Panal 


D-69 
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SUMMARY 


0  KBRA  Demonstration  Model 

Acquisition  -  multiple  views,  incremental  formalization 

Analysis  •  automatic  critiquing  &  completion,  reusable  requiremerits 

Communication  -  formal  representation,  requirements  documents 

0  Identification  of  knowledge  representation  issues 

Presentation,  Structured  Text,  Evolving  System  Description 

0  Formalization  of  reasoning  processes 

Inheritance,  Automatic  Classification,  Constraint  Propagation 
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Technical  Presentation  8 


"Insights  Into  the  Influence  of  Shared 
Userl  Customer !  Contractor 
Objectives  on  Project  Success" 


Mr.  Michael  S.  Deutsch 
Hughes  Aircraft  Company,  USA 


Empirical  Project  Success  Study  at 
Software  Engineering  Institute 


HUGHES 


•  Motivation:  paucity  of  significant  empirical  data  on 

software  project  management  process 

•  Goal:  identify  factors  that  discriminate  between 

success  and  non-success 

•  Feasibility  investigation- 

General  understanding 
^  Education 


Hypothetical  Model  of 
Project  Success 


HUGHES 


Cost 


Schedule 


User  Satitf action 


Reqnirementa 

Acbievcmeat 


Size 

Character 

Interfaces 

Business  Constraints 
Technical  Constraints 


Personnel 

Resources 
Dialofue 

MauKjment]  gcop.  DennlUon 
Risk  Management 
Planning/Control 
Interface  Management 


DEPENDENT  PREDICTIVE 

MEASURES  MEASURES 
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Management  Process  Model 


HUGHES 


User/customer/comractor 

dialogue 


User/Customer/  Contractor  Dialogue 


HUGHES 


o  Reconciliation  of  muitipie  user  needs 

••  .  .  .l5-U  ■  i-  '  ; 

Ohgoingxoliaborative.contacts  tp  assure 
correcirconterit  in  technical  requirements 

o  User(s)  participation  in  formal  design  reviews 

o  Representation  of  .user(s)  and  contractor  on 
customer  s'change  control  board 

i  ' 

o  Addressmg:6f:post  deployment  support  approach 


Exploratory  Data  Analysis 
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Management  Power  and 
Project  Adversity  Relationship 


Project  Performance 
and 

Net  Turbulence 
Relationship 
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COMPOSITC  PROJECT  PERPORMANCE 
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Intercorrelations  of  Predictive 
and  Performance  Measures 
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Project  Performance  and 
Business  Constraints  Relationship 


10 

9 

8- 

7- 

6- 

COMPOSITE  5. 
PROJECT  ^ 
PERFORMANCE 

4- 

3- 


H 


17.1 
“a  A 
Hi 


0  I 

livanbk 


42  *4 
,  “30 


7) 


“I  I  I - r 

2  3  4  5 


HUGHES 


.4  ) 

30 


.it 


n - ; - \ 

S  9  10 

unfavnnDic 


BUSINESS  CONSTRAINT  RATING 


Key  Points  Summary 


HUGHES 


•  Empirical  data  confirms  anecdotal  experience 
and  intuition 


•  Collaboration  of  user/customer/contractor  on 
technical  content  definition  affects  performance 


•  Technical  definition  uncertainty  with  other 
uncertainties  impacts  performance 


•  Adverse  projects  require  more  sophisticated 
management  including  requirements 
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Technical  Presentation  9 


"The  Serpent  User  Interface  Management  System" 


Mr.  Reed  Little 

Camegie-Mellon  University,  USA 


CanMqw  M*lk)n  Umfruiy 

Software  Engineering  Institute 


Introduction 

•  Problems 

•  Objectives 

•  Approach 

•  Use  of  Serpent 

•  Serpent  Architecture 

•  Serpent  Editor 

•  Transition 

•  Summary 


89-Se<penl-r»»d‘1 


Cam*9i«  Mlort  Unvwiny 

Software  Engineering  InstHute 


User  Interface  (Ul)  Problems 

•  User  interface  accounts  for  large  portion  of  life 
cycle  costs  -  in  some  interactive  systems  more 
than  70% 

•  Impacts  all  aspects  of  the  life  cycle 

-  requirements 
•  development 

-  sustaining  engineering 

»  changes  to  user  interface 
-  integration  of  new  input/output  (I/O)  media 


89-S»tp»nt-r»»d-2 
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Camcy*  MMon  UimtrMy 

Software  Engitwering  Institute 


Life  Cycle  Problems 

•  Requirements 

-  evolutionary,  not  well  specified 

-  written  specifications  inadequate  for  conveying 
"look  and  feel"  of  interface 

-  customers  may  not  know  what  is  practical 

-  customers  may  not  know  cost;  time  may  be 
more  important  than  dollars 

•  Design/implementation 

-  very  labor  intensive 

-  inadequate  existing  methods  and  tools 

-  manual  development  time  consuming  and  error 
prone 


a9-Swpw)f-r**d-3 


Carnty*  MMon  Unvwwy 

Sottwara  Engitwring  Inatitute  _ _ 

Life  Cycle  Problems  (cont.) 

•  After  system  completed 

-  frequent  and  complex  changes  required 

--  user  interface  intertwined  throughout  system 
--  customer  not  able  to  completely  comprehend 
interactions  until  system  is  delivered  and  in 
use 

-  difficult  to  take  advantage  of  new  I/O  media 
••  use  of  particular  hardware/software  media 

permeates  design  and  implementation 


89-S4fp»nt-r»»a-4 
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Cim«9w  MMon  Unvtnily 

Software  Engineering  Institute 


Objectives 

•  Make  user  interfaces  easier  to  specify 

•  Support  incremental  development  of  user 
interfaces  (prototypes) 

•  Provide  for  a  ’’bridge"  between  prototype  and 
production  versions  of  system 

•  Support  insertion  of  new  I/O  media  during 
sustaining  engineering 


SSSwpant-TMd-S 


C3>n«fi«  iMlon  Unvfnny 
Software  Engineoring  Inatitute 


Approach  to  Reducing  Ul  Probiems 

•  Provide  single  tool  which  supports  incremental 
specification  and  execution  of  interface 

•  Separate  concern  of  user  interface  specification 
and  execution  from  rest  of  system  concerns 

•  Apply  non-procedural  language  and  graphical 
techniques  to  user  interface  specification 


89~S»rp»fil-r0td-6 
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CtfiM^i*  MMon  UmwMy 

Softwift  Engiiwfing  InstituK  _ _ 

The  Serpent  UIMS 

•  Has  specialized  language  for  user  interface 
specification 

•  Supports  i/0  media  independent  applications 

•  Supports  both  prototyping  and  production 

•  Supports  multiple  I/O  media  for  user  interactions 

•  Supports  ease  of  insertion  of  new  I/O  media 


89Stfpt(il-f»0<t‘7 


Softwart  Engintftng  Instituw 


Serpent  Use 
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Canwqw  MMlon  Unn*rMy 

Software  Engineering  Institute 


Serpent  Architecture 


Application 

layer 

- - 


89-S»fp»nt-re«<)-9 


Cam«9w  iMon  Unmtrtny 

Software  Engineering  InstHute 


Slang,  UI  Specification  Language 

•  Based  on  production  model 

-  data  driven 

-  allows  multiple  threads  of  control 

•  Provides  multiple  views  of  the  same  data 

-  implemented  with  constraint  mechanism 

-  re-evaluates  dependent  values  automatically 
when  independent  values  modified 

-  applies  to  application  values,  I/O  media  display 
values,  and  local  variables 


89-Sarpant-fe«<l-lO 
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CanM9*  MMon  UnvwMy 
Software  Enginewing  Institute 


Prototyping 

•  Detailed  knowledge  of  Serpent  dialogue  model  is 
not  required 

•  Application  not  required 

•  Slang  allows  definition  of  local  data 

•  Serpent  automatically  enforces  constraints 

•  Reasonably  sophisticated  prototypes  can  be 
generated,  e.g.,  visual  programming 


Caintfi*  MMon  Unvcraity 

Software  Engineering  Institute 
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Canwqw  MMon  UravtrMy 

Software  Engineering  Institute _ 

Input/Output  Media 

•  Serpent  designed  to  simplify  the  integration  of  I/O 
media 

•  Currently  integrated 

•  digital  mapping  system 

•  XII  Athena  widget  set 

•  integrations  in  process 

-  Motif 

•  Open  Look 

•  video-based  mapping  system 

-  experimental  gesturing  system 


89-S»ri>»iH-rma-t3 


MMon  Unvwtiiy 

Software  Engineering  Institute 


Application 

•  Can  be  written  in  C  or  Ada 

•  Views  Serpent  as  similar  to  database  management 
system 

•  Creates,  deletes,  or  modifies  data  records 

•  Informed  of  creation,  deletion,  or  modification  of 
data  records  by  dialogue  layer 


89-S0ip4nt-r$»ch14 
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CanM9i«  MMon  UnvtrMy 
Softwart  Enginaering  Institute 


Serpent  Editor 

•  Layouts  of  user  interface  are  best  specified  or 
examined  graphicatiy 

•  Logic,  dependencies,  and  calculations  are  best 
specified  textuaiiy 

•  Serpent  Editor  has  two  portions 

-  graphical  part  for  examination  and  specification 
of  layout 

-  structure  part  for  textual  specification 

•  Implemented  using  Serpent 


Caffltfl*  MMon  UnwMy 
Sottwara  Enginewing  Institute 
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Cim*9w  MfHon  UnvMKif 

Softwif  Enginaaring  InstHuC _ 

Transition 

•  Encourage  use  of  Serpent 

•  Provide  close  support  fpr  selected  sites  during 
interim  period 

•  Publicize  Serpent 

•  Distribute  via  electronic  media 

•  Commercialization 
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Ctmtgm  IMlon  Unnwsily 

SoNwareEngi'  .aring  Institute  _  _ 

Status 

•  Serpent  (w/o  editor)  in  alpha  test 

.  Available  for  SUN  and  VAX  (ULTRIX) 

•  Beta  version  of  Serpent  (including  editor)  available 
Fall  ’89 
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Cam«9N  Mellon  Untv«n/(y 

Software  Engineering  Institute 


Summary 

•  Reduces  effort  for  specifying/modifying  user 
interface 

•  Provides  for  evolutionary  changes  of  I/O  media  In 
fielded  system 

•  Simplifies  post  deployment  user  interface 
modifications 

•  Provides  seamless  path  from  prototype  to  fielded 
system 


89'S*fP*nl-f»»<t-20 
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Technical  Presentation  10 


"Using  Joint  Application  Design  (JAD) 
Techniques  to  Accelerate  the 
Requirements  Definition  Process" 


Mr,  Robert  C,  Fink 
Performance  Resources,  USA 


\  THE  CHANGING  MARKET 
ENVIRONMENT:  CAUSES 

EMPHASIS  ON  A  GLOBAL  MARKETPLACE 

EC  ’92  -  EUROPE  AS  ONE  TRADING  PARTNER 

THE  FAR  EAST  -  AGGRESSIVE  COMPETITORS 

MERGERS,  ACQUISITIONS  -  MORE  BIG 
PLAYERS 


THE  CHANGING  MARKET 
ENVIRONMENT :  EFFECTS 


INCREASED  LEVEL  OF  ACCEPTABLE  RISK 

NEED  FOR  COMPETITIVE  ADVANTAGE 

HIGHER  PRODUCTIVITY  REQUIRED 

FLEXIBILITY  TO  ADAPT  QUICKLY  TO  NEW 
CONDITIONS 


THE  CHANGING  SYSTEMS 
ENVIRONMENT 


•  EMPHASIS  ON  IMPROVED  DATA 
MANAGEMENT  IN  INFORMATION 
ENGINEERING 

•  RELATIONAL  DATA  BASE  PRODUCTS 

•  IBM'S  REPOSITORY  -  CORPORATE  DATA 
RESOURCE 

•  SHIFT  IN  THE  LIFE  CYCLE 

•  TOOLS  SUPPORTING  LIFE  CYCLE 
PRODUCTIVITY 


Performance  Resources,  Inc.  (c)  1989 


JAD: 


JOINT  APPLICATION  DESIG 


A  GROUPWARE  CONCEPT:  TEAM-BASED  TECHNIQUE 

LED  BY  A  TRAINED  FACILITATOR 

SUPPORTED  BY  A  TRAINED  ANALYST/DOCUMENTOR 

CENTERED  AROUND  A  WORKSHOP 

FOCUSED  ON  CONSENSUS-BASED  DECISION-MAKING 

USED  FOR  ADDRESSING  INFORMATION  ANALYSIS/BUSINESS 
MANAGEMENT  ISSUES 


Performance  Resources,  Inc. 


(c)  1989 


D  = 

CREASED  PRODUCTIVITY 


FtibChMikVA  ZIMI 
70)445>MM 


^WITHOUT  JAD:  AS  MUCH  AS  35% 
^FUNCTIONAL  REQUIREMENTS 
MISSED.  ADDITIONAL 
iMENTS  ADD  NEARLY  50% 
3E. 

•H^S  THAN  10%  OF 
[ON^mMQUIREMENTS 
I^SEDSroiFJ^iAND  PROTO- 
'li^i;lE^S^.TOANf5%:MISSED 
“IMINIimurODE.ApDEp. 


(c)  lilt.  rafonMa 
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CHANGING  FOCUS 


SYSTEMS  FOCUS 

BUSINESS  FOCUS 

Technology  Driven 

"Back  Office"  Transaction  Driven 

Hardware  and  Software  Limiting 
Single-Function  and  Organization 
Operational  and  Tactical  Role 

Business  Decision  Driven 

"Front  Office"  Supported  -  MIS  and  DSS 
Increased  Hardware  and  Software  Capabilities 
Multi-Function  and  Cross-Organization 
Strategic  and  Competitive  Edge  Role 

V _ ! 


Performance  Resources,  Inc. 


(c)  1989 
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SYSTEMS  PROFESSIONAL 


PAST 

PRESENT 

Computer  Expert  "Gurus" 

Systems  Professionals  are  Consultants 

Reactive  to  Users 

Catalysts/Planners  in  Business  Change 

Users  New  to  Computers 

Users  Have  Experience  with  Systems 

Technology  is  all  Important 

Choose  Technology  to  Fit 

Programmer/Analyst  is  Craftsman 

Programmer/Analyst  is  Engineer 

Programmer/Analyst  Dominates 

User  -  Systems  Parmership 

Maintenance  -  Large  Role 

Maintenance  -  Decreasing  Role 

Performance  Resources,  inc. 

(c)  1989 

•  METHODOLOGY:  INFORMATION 
ENGINEERING 

•TOOL:  CASE 

•  TECHNIQUE:  JAD 

•  ENVIRONMENT:  FUSION  CENTER  * 

The  name  "Fusion  Center"  is  drawn  from  the  U.S.  Army  Corps  of  Engineers 
Management  Center  under  the  technology  transfer  program  of  the  U.S.  Government. 


Performance  Resources,  Inc. 


(c)  1989 


JAD  EVOLUTION 


FIRST  GENERATION  JAD 

NEXT  GENERATION  JAD 

FOCUS  ON  PROCESS 

FOCUS  ON  DATA 

TRANSACTION  ORIENTATION 

TRANSACTION  +  MIS/DSS 

USER  PARTICIPANTS 

TIGER  TEAMS  =  BUSINESS  +  SYSTEMS 

SCRIBE  AS  DOCUMENTOR 

DESIGN  ANALYST/CASE  USER 

APPLICATION-LEVEL  ONLY 

ENTERPRISE.  BUSINESS  AREA.  AND 
APPLICATION  LEVELS 

USER  REQUIREMENTS  ONLY 

USER  REQUIREMENTS  AND  LOGICAL 
DESIGN 

Performance  Resources,  Inc. 


(c)  1989 


WORKSHOP 
KEY  JAD  MODULES 


MODULE  I: 
WORKSHOP 
PREPARATION 


Opentional| 

Guidelines 


Workshop 

Agenda 


MODULE  III: 

DATA 

MODEL 


ERD's 


MODULE  U: 

CONTEXT 

MODEL 


_  Functional 
1  Fiameworic 


.  Normalized 
Data  Model 


Q/D/Ps 


Access 


MODULE  IV: 

Functional 

.  *»  '■ 

PROCESS 

Decomposition 

I/O's 

Interfaces 

MODEL 

DFD’s 

Dependency 

Diagrams 
Process/Entity 
Matrix 


Menus 


Workshop 

Closure 


Performance  Resources,  Inc. 


(c)  1989 


INDEPENDENT 
DATA  ANALYSIS 


•  Corporate  Architecture  as  a  Corporate  Asset 

•  Elimination  of  Duplication 

•  Shared  Data  -  Models  Within  the  Architecture 

•  Data  Separate  From  Business  Process 


.  -  ■■■  - " 

Performance  Resources,  Inc.  (c)  1989 


- - - 


HIERARCHICAL 
PROCESS  ANALYSIS 

•  TOP-DOWN  ANALYSIS  OF  BUSINESS 

•  APPLICATIONS  SUPPORT  CORPORATE 
BUSINESS  STRATEGY 

•  FUTURE  ORIENTATION 

•  FLEXIBLE  MODEL  TO  MEET  BUSINESS 
CHANGES 


V _ / 

Performance  Resources,  Inc.  (c)  1989 
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JAD  DELIVERS 

•  IMPROVED  ANALYSIS/DESIGN  QUALITY 

•  REDUCED  ANALYSIS/DESIGN  TIME/COST 

•  IMPROVED  OWNERSHIP  OF  SOLUTION 

•  EARLY  ISSUE  IDENTMCATION/RESOLUTION 


V _ / 

Performance  Resources,  Inc.  (c)  1989 


Performance  Resources,  Inc. 


(c)  1989 


•  SPECIAL  FACILITY  DESIGNED  TO  SUPPORT 
GROUP  DECISION-MAKING 

•  AUTOMATED  DECISION-MAKING  TOOLS  AND 
CASE  TOOLS 

•  TRAINED  FACILITATOR  AND  DOCUMENTOR 

•  USE  OF  SPECIAL  MATERIALS  -  WHITE  BOARD 
WALLS,  COMPUTER  PROJECTION,  MOVABLE 
FURNITURE  AND  WALLS 


Performance  Resources,  Inc.  (c)  1989 


^  EIGHT  CRITICAL 
SUCCESS  FACTORS 

1.  EXECUTIVE-LEVEL  COMMITMENT 

2.  EDUCATED  SYSTEMS  AND  USER  TEAM 

3.  EXPERIENCED  FACILITATOR 

4.  CASE  SUPPORT 

5.  DEFINED  PROJECT  OBJECTIVES 

6.  DEHNED  PROJECT  SCOPE 

7.  DEFINED  PROJECT  DELIVERABLE 

8.  LOGISTICAL  RESOURCES 


This  page  is  intentionally  left  blank. 
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Technical  Presentation  11 


"ADA  Box  Structures  for  Object-Oriented 
Software  Development" 


Mr,  Edward  R.  Comer 
Software  Productivity  Solutions,  USA 


Welcome  to  Ada  Box  Structures! 


'•  Ada  Box  Structures  provides  a  disciplined  means 
to  analyze  software  systems  in  an  object-oriented 
fashion. 

•  As  an  analysis  method,  Ada  Box  Structures 
provides  a  rigorous  framework  for  describing 
objects  from  various  perspectives:  static  and 
dynamic,  internal  and  external. 

•  The  box  structures  of  black  box,  state  box  and 
clear  box  provide  different  views  of  any  object  in 
increasing  levels  of  detail  and  with  increasing 
visibility  into  the  object. 

•  Ada  Box  Structures  fills  a  gap  in  object-oriented 
methods  by  providing  a  rigorous  method  for 
discovering  application  objects. 


Object-Oriented  Development 


Advantages  of  Object-Oriented  Development 


•  Provides  a  single,  consistent  model  that 
requires  no  “great  mental  leap’*  from 
analysis  to  design  and  thus  increases 
traceability  and  maintainability 

•  Matches  the  technical  representation  of  the 
software  system  more  closely  to  the 
conceptual  view  of  the  application 

•  Provides  a  stable  framework  for  analyzing 
the  problem  domain  and  for  levying 
requirements 

.  Supports  implementation  using  abstract 
data  types 


An  object  is  an  abstract  data  type,  which  encapsulates 
data  and  provides  a  set  of  predefined  operations  to 
manipulate  and  access  that  data. 

An  object  class  is  a  collection  of  object  instances  with 
common  attributes  and  a  common  set  of  operations. 

An  operation  defines  an  object’s  capacity  for  action, 
response  or  functioning. 

A  stimulus  is  an  external  request  for  an  operation  made 
upon  an  object. 

Transactions  are  behavioraliy  related  sequences  of 
stimuli  and  responses. 
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More  Definitions 


Attributes  detine  the  data  pertinent  to  each  instance  of 
an  object.  Attributes  encapsulate  stimulus  histories. 

The  state  of  an  object  is  determined  by  the  values  of  its 
attributes. 

Objects  may  be  nested,  defining  subobjects  that 
contribute  to  the  state  and  behavior  of  a  parent  object. 

A  relation  is  a  mapping  or  association  between  objects. 

Constraints  denote  facts  about  objects  that  specify 
behavior  or  limitations  on  behavior  or  state. 


Being  able  to  look  at  problems  from  different 
perspectives  is  a  powerful  way  to  reason  about  and 
understand  systems.  These  kinds  of  perspectives 
are  of  particular  use  in  understanding  and  analyzing 
objects: 

•  Static  and  dynamic  perspectives  of  objects 

•  External  and  internal  object  perspectives, 
and  inter-subobject  perspective 
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Object  Perspectives 


Statle  Dynamic 

Parapaethm  Parapactiva 


Extamai 

•  SNmul 

•  Operation  constraints 

Objact  Modal 

•  Rasponsas 

•  External  object  behavior 

•  Tranaacbont 

•  External  transaction 

•  Oparaiions 

models 

Intamal 

•  AnnbUat 

•  Attnbute  constraints 

Objact  Medal 

*  Operational  spaaii* 

cation  ot  behavior 

lntar.Subob|aet 

•  Subobjaets 

•  Relation  constraims 

Modal 

•  Clasailication  structura 

•  interaction  paths 

•  Subobjact  relations 

•  Subobjeo  interaction 

models 

The  Black  Box 


The  black  box  view  represents  the  external 
object  model. 


Black  Box 


The  external  object  model  considers  only 
those  aspects  that  can  be  viewed  from  the 
outside. 
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The  State  Box 


A 


The  state  box  view  represents  the 
internal  object  model. 


Stata  Box 


StImukM 


1  oeiKi 

r=i 

R»ssonM 

^  AltnMM  J 

The  internal  object  model  statically  defines 
the  attributes  of  the  object  that  the  object 
must  remember. 


The  Clear  Box 


The  clear  box  view  represents  the 
inter-subobject  model  of  nested  subobjects. 


SUfiukii 


The  inter-subobject  mode/ statically  defines 
the  subobjects  that  are  nested  within  the 
object,  analyzes  the  classification  structure  of 
objects,  and  defines  the  relations  between 
subobjects. 
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Box  Structures  Expansion 
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Box  Structure  Hierarchy 


First  Uvtl  Slick  8a« 


SIM  Sox 


Elaboration  of  black 
box  into  equivaltnt 
stats  box  and  ctsar 
box  rsprssentations 


Sscond  Lsvti 
Osoompositjon  ot 
cisarbox  into  black 
boxobjaat 
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Ada  Box  Structures: 

A  Framework  for  Systems  Analysis 


The  Ada  Box  Structures  Method  provides  a 
framework  for  systems  analysis.  This  framework 
guides  the  integration  and  application  of  several 
different  analysis  methods.  The  result  of  the 
analyses  is  information,  expressed  in  text  and  in 
graphics,  that  records  the  understanding  of  the 
system. 
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Ada  Box  Structures 
Work  Product  Representations 
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Selection  of  Representations 


There  are  a  number  of  important  factors  to  consider  in 
selecting  specific  techniques: 

•  Maturity  of  the  technique  with  respect  to 
object*oriented  specifications 

•  Complexity  of  the  system  to  be  specified 

•  Degree  of  detail  and  rigor  that  is  desired  in  the 
specification 

•  Familiarity  and  experience  of  the  organization 
with  the  technique 

•  Level  of  expertise  of  the  analysis  personnel 

•  Availability  of  training  in  the  technique 

•  Availability  of  automated  tools  to  support  the 
technique 

•  Degree  of  integration  possible  between  tools 


The  13-Step  Ada  Box  Structures  Process 


UmtBm 


. . 


1.  Define  object  stimuli  and  responses 

2.  Identify  object  operations 

3.  Define  informal,  external  object  behavior 

4.  Conduct  transaction  analysis 

5.  Discover  state  requirements 

6.  identify  attributes 

7.  Define  operational  specification  of  behavior 

8.  Conduct  state  analysis 

9.  Identify  clear  box  subobjects 

10.  Classify  subobjects 

11.  Define  subobjects*  relations 

12.  Define  interaction  paths 

13.  Conduct  object  interaction  analysis 

J 


Steps  1-4: 
Black  Box  Expansion 


1 .  Define  object  stimuli  and 
responses 

2.  Identify  object  operations 

3.  Define  informal,  external  object 
behavior 

4.  Conduct  transaction  analysis 


Black  Box 


SPS 


Black  Box  Expansion 


1.  Define  object  stimuli  and  responses  2.  Identify  object  operations 


3.  Define  informal,  external  object 
behavior 


4.  Conduct  transaction  analysis 
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Steps  8- 13: 
Clear  Box  Expansion 


8.  Conduct  state  analysis 

9.  Identify  clear  box  subobjects 

10.  Classify  subobjects 

11.  Define  subobjects’ relations 

12.  Define  interaction  paths 
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Clear  Box  Expansion  (con't) 


12.  Define  interaction  paths 


13.  Conduct  object  interaction  analysis 
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Incremental  Expansion  Process 


. 

AndyM 

1 

Invannn 

Advantages  of  Ada  Box  Structures 


A  small  set  of  structuring  concepts  used 
repeatedly 

A  rigorous  process  with  verification 

Small  steps  of  invention 

No  restrictions  placed  on  the  order  of 
elaboration  (e.g.,  to|>down  vs.  bottom-up) 

A  “place  notation”  for  documenting 
specification  details 

Directly  evolvabie  into  an  Ada  object-oriented 
design,  improving  traceability  and 
maintainability 


SPS 
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Technical  Presentation  12 


"A  Prototyping  Methodology 
Applied  to  Tactical  C2  Systems" 


Mr.  Martin  Morel 
Le  Groupe  CGI,  Canada 


^  Why  Prototyping  is  needed... 


Conventional  Methodologies  -  impose  too  much  responsibility  on  the  developer  with 

respect  to  the  accuracy  of  system  development. 

•  Oeliverables  prioritize  heavy  documentation  rather  than 
functioning  and  demonstratable  software. 

•  user  group  review  meetings  become  less  productive  and 
tend  to  be  superficial  as  a  means  to  gathering  user 
requirements. 


User 's  Role  -  Users  heve  too  little  involvement  in  the  development  of  the  system. 

•  Lack  a  sense  of  "ownership"  In  the  resulting  system. 

•  Only  "see"  the  system  once  it  is  developed  •  no  opportunity  for 
useful  feedbeck  during  critical  development  stages 

•  System  remeins  abstract  in  its  early  stages  of  design. 


Developer's  Role 


•  Experiences  difficulty  to  accomplish  his  /  her  basic  function: 
->  to  PRODUCE  USEFUL  information  systems  which  respond 
to  the  USER'S  REQUIREMENTS. 

■  Work  serves  to  teed  the  methodology  rather  than  the  users. 

■  Often  has  to  struggle  to  "learn  the  system". 


CQI 


^  The  E.C.C.O.  Project 


Engineer  Command  and  Control  Operations 
Mobility  /  Counter  -  Mobility  Function 
Canadian  Land  Forces 


Brief  History  of  ECCO 
Software  Developments 


2  Versions  written  to  date  using 


Conventional  Methodology 


3GL  Technology 


Built  with  a  minimum  of  user  input 
Resulting  system: 

E-R  Diagram  of  8  entities,  on  3  pages 
Approx.  10  input  screens,  10  reports 
Only  a  very  partial  coverage  of  the  requirements 


Single  •  user,  PC  Based 


Never  completely  accepted  by  the  users 
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^Requirements  prior  to  Prototyping  Approach 


Log  Obstacle  Tasks 


Maintain  Resource 
Descriptions 


Keep  up  to  date  specifications  of  Obstacle  •  Task  activity 
descnptions; 


CODES 

DESCRIPTIONS 

STATIC  OUANTITIES 

ETC... 

Maintain  descriptions  of  different  types  of  resources  used  by 
Obstacfe*  Task  types 


Result  •  Production  of  a  large  amount  of  documentation 

•  Little  software  produced  tor  known  reouirements 

•  Requiremems  analysis  has  not  gone  in  deoth  ...  unknown 
requirements  remain 

— — - cgi 


^Requirements  with  Prototyping  Approach 

(SUMMARY) 


Obstacle  •  Task  Planning  ‘  *°*'°'*'  '  Counter  •  Mobility  tasks  m  a  tactical 

Situation.  Support  multi  -  plan  operations. 


Mobility 

Counter  -  Mobility 

Survival 

General  Support 

Resource  and  Work  Schedule  .  calculate  work  schedules  and  ail  required  resource  types  to 
Calculation  cany  out  M/ CM  tasks 


Time 

Personnel 

Equioment 

Vehicles 

Mines  1 

Explosives 

Fencing 

Accessones 

Stores  Dump  Management  .  Xetp  an  update  account  of  dump  store  contents  and  allocations 

(inventory  control  approach) 


Orders  and  Map  Overlays  •  Produce  detailed  miliiary  orders  and  engineer  clans,  maintain  a 

Production  graphical  representation  ol  oostacle  symools  ovenays  on  a 

terrain  map. 


cgi 


E.C.C.O.  Prototyping  Status 


New  Objectives 


'  Ensure  that  user  requirements  are  completely  speofied  through  the 
prototyping  process. 

’  Use  prototyping  incremental  approach  to  system's  development. 
The  Prototype  tMcomes  the  System 


Software 


•  Current  architecture  phase  has  already  defined: 


Over  60  input  screens 


Over  80  Data  Tables 


Documentation 


Over  70  reporting  functions  6  Complex  Calculational  Functions 


•  With  the  prototyping  approach,  the  documemation  gradually  builds 
up  as  the  user  requirements  are  refined.  Each  component  of  the 
system  is  documented  using  a  data  dictionary  and  and  E  •  R 
modeling  CASE  tool. 

Data  Model  currently  covers  60  entities.  7  modules 
displayed  on  18  pages 


cgi 


ECCO  Technological  Environment 


4GL  DBMS 


Oracle  with  C  interfacing 


Multi*  User  O.S. 


Terrain  Analysis 
Interfacing 


Geographical  Information  System  on  Graphic 
Workstations 


Methodology 


Protoguide  •  A  Prototyping  Methodology 


Prolo'SQL*  Data  Dictionary, 

mini  Configuration  Management  tooi, 
documentation  generator 


cgi 
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What  is  ProtoGuide  ? 

Prerequisites 

a  Development  Guide 

a  4th  generation  language 

a  Prototyping 

0  Relational  D.B.M.S. 

a  The  prototype  "becomes" 

the  system 

Advantages  Caution 


a  Improved  user 
participation 

a  Reduced  development 
costs 

a  Reduced  operational  costs 

a  Reduced  duration 

□  Get  the  right  system  the 
first  time 

- - cgi 


a  Manage  modification  requests 
0  Role  of  participants 


|/-ProtoGuide 

Overview 


Phases 


The  development  is  organized  into  phases;  at  the  end  of  each 
phase,  specific  deliverables  must  be  oroduced 


Preliminary  Study  Architecture 


Prototyping  Construction  Installation 


Deliverables  The  deliverables  consist  of  system  components  and  end  of  phase 

reports 
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Phases 


Preliminary 

Study 

Actual  Situation 

Definition 

Recommendation 

Architecture 

Planning 

Organization 

Standardization 

Prototyping 

Demonstration 

Experimentation 

Specification 

System 

Construction 

Construction 

Inspection 

Preparation 

Installation 

Verification 

Installation 

Evaluation 

study  and  evaluate  actual  situation 

Set  objectives,  define  the  system 

Solutions,  profitability,  recommendation 

Plan  overall  develooment  project 

Organize  development  project 

Set  development  standards 

Present  an  operational  prototype 

Use  the  prototype  to  validate  it 

Complete  details  for  system  construction 

Construct  according  to  standards  and  specs. 

Verify  conformity  to  standards  and  specs. 

Prepare  installation 

Detailed  verification  of  correct  operation 

Install  for  day  to  day  usage 

Evaluate  the  system  and  the  project 

■  Overview  (phases)- 


Preliminary 

Study 


Architecture  Prototyping  System  Installation 

Construction 


Overview  (Prototyping  vs  Analysis) 


Prototyping 


Menus ... 


ECCO 

Minefields 

Craters 

Abattis 

Bridges 

Demolition 


Screens ... 


il 

SI 

Mines  Used 

Qty. 

1231 

10 

5465 

5 

4446 

Reports ... 


Dump  Inventory 

store.  Desc.  Qty  Power 
Mine  Resource  Stores 
1231  Conv.  Mines  13  500 

5465  Scatt.  Mines  50  350 


User  Guide ... 


Conv.  Minefields  Editor 


Validations 

Mm*  The  iTCDo  IMS  lyp«  may 
Fietd  otaAy4cnar.coof. 
Min«  Thf  m«>«tVMrMoufC* 
Typa  must  fiitt  n  thf  Oump 


_ Calculations 

OtnMy  Wnanoiy.  •moptfiad. 

total  Ptniity  of  ttia 
(•oUitracaJcuUiad  as 
SizaxOty.xOonsiy. 


Oanaxy  wnt n  ina  nrima  qty. « 
mocMtfd  racatcuiat*  tna 
total  bantxy  of  tna  mma 
liakd  uaing  tt>«  mna  giy 
and  Iha  corraaoonding 
standard  oansxy  o(  tna 
mma  tiaid.  Tha  aiact 
lorrnula  dapanoi  on.. 
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Deliverable 


Programs 


Menus 


Interactive  Proqrams 


Reoorts 


Batch  Processing 


Data  Base  Management 


System  Documentation 


Development  Guide 


Inteqrated  Tests  Guide 


Conversion  Guide 


Installation  Guide 


Maintenance  Guide 


User  Documentation 


System  Overview 


Training  Guide 


User  Guide 


Quick  Reference  Guide 


Reference  Guide 


End  of  Phase  Reports 


Preliminary  Stud 


Architecture 


System  Construction 


Installation 


cgi 
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Interactive  Programs 


Preliminary 

Study 


Architecture 


Prototyping 


System 

Construction 


Installation 


Actual  Situation 


Definition 


Recommendation 


Verification 


Installation 


Evaluation 


Verify  correct  operation 


Install  in  production  environment 


cgi 
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Preliminary 

Actual  Situation 

Study 

Definition 

Recommendation 

Architecture 

Planning 

Summary  descriotion  of  reports 

Standardization 

Prototyping 

Demonstration 

Selection,  sorting,  report  data  layout 

Experimentation 

Verify  usefulness  using  real  data 

Specification 

Specify  volumes,  frequencies 

System 

Construction 

Performance 

Construction 

Inspection 

Verify  conformity  to  standards 

Preparation 

Installation 

Verification 

Verify  correct  operation 

Installation 

Install  in  production  environment 

Evaluation 

cgi  - 


User's  Guide 


Preliminary 

Study 

Actual  Situation 
Definition 

Recommendation 

Architecture 

Planning 

Organization 

Standardization  ]  Specify  user  interface  standards 

Prototyping 

Demonstration 

Describe  prototype's  processes  and  data 

Verify  accordance  with  the  prototype 

Specification 

Specify  all  process  details 

System 

Construction 

Construction 

Inspection 

Verify  conformity  with  standards 

Preparation 

Installation 

Verification 

Verify  conformity  with  system 

Installation 

Evaluation 


^ECCO  Example  -  Menu  and  Screen 


Preparation  Material 
for  User  Group 
Meeting  #1 


-  Menu  &  Menu  Documentation 
•  Conventional  Minefields  Editor  Screen 


Meeting 

Notes 


•  User  Group  Meeting  #1  •  Conventional  Minefields  Editor 

•  User  Group  Meeting  #2  •  Conventional  Minefields  Editor 


Material  Prepared 
after 

User  Group 
Meeting  #2 


-  Menu  and  Menu  Documentation 

•  Conventional  Minefields  Editor 

•  User  Documentation 

•  Developer's  Documentation 
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OBSMD 


DRK7  -  ECCO  sornowB  frotorfb 

Obmtmclm  Hena 


<^*inn»  Suaaaxy  dascxipcion  of  aanu  options 

This  secucn  picsencs  a  sunmiy  oescnccicn  oi  eacn  ccusn  pcesenced  in  cha  seni 

Cbsracle  Class  Ertirnc  The  rtwarle  class  eoitcx  is  actvaliy  <xmaea  of  savetal  screens.  The  first  of  these 
alloa  the  user  to  define  and  pout  to  a  ‘class*  of  astacles  viucn  gcip  cooechec 
obstacles  of  a  sane  type.  Sy  annum  to  class,  the  usee  an  ‘emana’  to  a  seccMaiy 
sceen  Miicn  coreains  the  aoecific  licuc  data  required  to  define  an  ctva-jrle  type  within 
that  class.  The  sixpoi^  etstacle  classes  are:  Abacus,  yeaoetijie.  eno^  rwmniirinn. 
carers,  Cthec  Dninliticn,  Minefields,  Axi-Tanic  Ditches  and  fences. 
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DRS7  -  Ecco  sorrmrat  protorpk 

Engineer  Tasks  Module 
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a^mcf 


Sii— iry  deacripcion 


OiapXayed  Menu 
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Engineer  Tasks  Module 
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cpuaaa  Sumaary  description  ot  aenu  options 

this  secucn  presses  a  sumaiy  oescrueion  ot  &>ai  cption  pressted  in  cm  sou 

I^e  ctetads  class  sdttcc  is  actual  ly  exposed  ot  sc/eral  screens.  I^e  lirst  o<  Usse 
aUcM  chi  user  to  deXine  am  couc  to  a  *das3*  ot  aist.icles  tiudi  qcop  tooechu 
nhsticUs  ot  a  same  C)pe.  By  pbueim  co  class.  c.ne  usee  can  'essm*  Co  seonsuy  screens 
vtuch  ocnuin  ens  speoiic  uzer  oaci  required  co  octree  an  cnsc^e  type  vichin  Out 
class.  Ihi  svxpoited  oOscacle'  classes  are;  Acatus,  Beacetree.  Bodoe  Damlitim.  Caters, 
ether  Demlution.  Cocvenuonal  Hinetields.  ocatceactle  Kreetields.  Ami-'IMc  Ditches. 
Fences  am  Rxoy  Ttans.  Anocner  osenc  ccstacle  type  ras  also  oeen  included  called 
'XteS*.  eiese  types  are  used  by  hicn  lecel  aixom  uuts  to  oian  entire  tield  axes  cn 
vhicn  eraresec  cnrccrsicoility'acuvites  an  to  caxe  place.  ' 

.•■fxiiity  nuts  Efliter  The  FtbUity  Tasks  CcUtcr  u  used  co  sceoiy  am  Otyreerc  Che  cesouree  nauunwes  tot 

enqreeec  Mcdlity  tasks.  Geneally.  desi  casics  are  rl.imtied  as;  cr.e-jri»  breachreq. 
couce  Baucennoe  oonsc ruction,  betaptnq,  am  nver  aossuq. 

Survival  Tasks  Editor  The  Survival  Tasks  Editor  is  used  to  .ccecitiy  am  docurerc  the  resouroe  requimres  of 

enqinear  survi'/al  casks.  Generally,  these  pertare  co  sroud  di^req  activitits  such  as 
ciendae  and  torrifirar.im. 

Gerarai  suxoct  iksks  Ihe  Gncal  Seaport  Tasks  editor  is  used  co  speoty  am  omrcrc  c.**  rsoumnnts  of 
mirnr  vanois  oreetal  sipport  activities  tallira  unoer  c.*e  respcnsibilicies  ot  enqreears. 

ESaaplas  an;  DSD,  lacer  r^cly,  civim,  t.v-iiiriev  oxstiuctim. 


Comar  nxiUty  Tasks 
Editor 
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Couatmr  Mobility  Tasks  Editor 

Ssssij  Siiaairjr  OaacripCioa  of  tha  Procassing 

liie  ctnrarlt  class  edkot  u  actually  angpcaaa  of  seveial  soeens.  He  fust  of  tlsse 
alloa  tlB  user  to  defim  and  pouc  co  a  ‘class*  of  disracles  i4ud>  otct^  cooecxEc 
rhyaclfs  of  a  same  type.  By  paucinp  to  class,  tlE  usee  can  ‘escano*  co  seccnoaiy  screens 
uhidi  coRaui  Ue  ^rnfv,  siox.  data  zeoaixed  co  define  an  msfjrie  type  uiclun  uec 
class.  He  sippoiced  chirafle  classes  an:  Ahattis.  Beacecese,  Bnrty  Demlicicn,  Ccacecs, 
CtlEC  nwnlirinn,  Ccnvencional  Minefields,  ScatteranUi  Minefields,  Arti-ianlc  Oiccnes, 
Fences  and  Booty  leaps.  Anxnet  gerecac  cascade  type  has  also  tsen  included  called 
*ZHS*.  Hess  types  ace  used  by  hii^  level  oameril  isiits  to  plan  emte  field  zones  cn 
whicb  eodinaec  coinarssbility  accivites  ace  co  take  place. 


...Cage  7 


Gaivencicnal  tdne  Field  Cbkades 
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Couaesr  Mobility  Tasks  Editor 


OHEOBS  -IS 


■;ia7.’'^enii  .Minefields 

:able 


irilCbscaoie  r,pe 


(Fllctsc-yae 

Sescciccion 


(FllMineneld  Density 


(FilNintET  of  Bows  in 
Minefield 


(FSISccpping  Pouec 


(F6|Hinefield  Placoienc 
Steed 


He  Convaucnil  KinefiElds  cable  is  used  co  scon  Che  basic  technical  speoificacicns  of 
engmeer  scandacd  ocnventional  odnefield  types.  These  types  an  assioned  kandacd  codes 
used  co  quicUy  and  uuguely  identify  chen  mer  assigning  a  cbscacle-casK. 

am  4 

He  ooiwRional  minefield  type  code  is  a  feui  chacaaec  field  used  to  uuquely  identify 
a  standiid  oonvemoEl  Binefield  oonfiguzacicn.  Hus  code  is  eneced  chitun  the 
*Conf<nunnal  Minefields  EdiCoc*  and  its  naincenaice  is  tne  nspcnsibility  of  Che  syscan 
pilot  oc  admnistiaeoc. 

am  30 

He  oonvencional  minefield  description  is  a  fnc  cest  field  used  to  assooace  a  s.xit 
descnpcion  of  a  scandacd  oonvercional  minefield  to  cne  minefield  type  oode.  Hus  meet 
desoogxion  is  then  displayed  ucii  Che  minefield  type  in  ether  pacts  of  ch:  BOOO  syscan 
CO  enhnge  cIe  significanoe  of  che  minefield  cype  onanonic  code. 

)U«n  s 

The  densicy  dumhx  Che  lutEr  of  ccnvemonal  mines  placed  per  «necer»  in  a 

scandud  oonvencional  minefield  ornifigunr.ioi. 

HMCKS 

He  nuetar  of  ecus  of  oonvencional  minefields  Chat  this  type  of  minefield  cbscacle  type 
ooncains. 

oms 

He  scopfung  peuer  is  a  pecoacage  value  beteen  0  and  lOO  indicating  the  peebabilicy  of 
steppang  trmn/  vehicles  fcoi  passing  chcouA  che  minefield. 

lUOX  6 

He  plaoam  soeed  denotes  che  tune  cequictd  to  set  eg  this  type  of  minefield  obstacle. 
(Xisi^y,  chis'valueis  egessed  in  ceiss  of  sectioi-houcs  or  ccocpdoucs. 
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(niHmlieid 
'Jnit  of  Heasutc 


Mcnad 


Obsuclt  Feaoisoes 
»bit 


(VllBeaouicB  lype 


(VllBtsuios  Quarucy 


OfflR4 

The  plaoBienc  speed  uuC  of  oeesuie  u  directly  esxaaced  with  cPe  aanefield  placom 
speed.  It  Id  a  4  diaiacer  code  used  to  indicated  tne  uut  of  seasuie  used  to  ue 

plaamft  steed  (usually  in  secticrHputd  cc  trccp-noursl .  Ilus  code  is  validated  fios 
tile  aXD  unit  .Measures  lable*. 

CHAR  10 

Qe  laying  meted  rtesfnhes  the  pahcmle  iiechod  used  to  lay  the  sxverticnal  mnes  foe  a 
given  oanenticnal  minefield.  Its  ■.aluu  are  either  aanal-surfaoe  OflSUl ,  mnBl-bucies 
Onat).  mecfianical-suifaai  tCSUl.  mecnanial-tuiied  OfSUl. 


ihe  cfaeacle  resouroi  table  holds  the  type*  codes  of  all  ccnsuanle  and  non-ecnsuable 
resDurou  required  tv  <d«tacle  types.  Used  by  tie  Cbstacle  editors,  it  defines  for  eadi 
ctataele  type  of  a  given  class  (ex;  Ccnventimal  times.  Craters  etc.)  the  resource  types 
required  to  put  that  ctvitaele  into  place. 

OAR  4 

liis  resource  type  denotes  a  ccnsuieble  or  non-oonsurable  resource  code  reonred  to  place 
an  cbstacle.  liie  resource  type  ooae  is  defined  wichm  a  specifio  cnstacle  class. 

.‘USE  5 

Ha  resource  quantity  field  denxes  the  qtacity  of  a  sceofic  ocnsuieble  or 
nxt-aonstEBOle  resource  required  to  place  an  miranle  of  a  given  type.  Its  value  is 
aq'aes.i«i  in  terms  of  the  basic  iruts  of  measure  oefined  for  a  giv«  resource. 


DREV  -  ECCO  CODE  VAiUE  TABLES  FOR  SOMMARlf  FORM  D0CUMENTA710M 
PcotoSQL  Form  Ooeufflentec 


Field  attributes 


A  Database  field 
B  Fcimacy-)cey 
C  Copy  field  value 

fcoa  bloclc  fill-in  exist 
0  Copy  field  value 

fcoa  field  fill-in  exist 
E  Default  value  exist 
F  Displayed 
G  Input  allowed 
H  Query  allowed 
I  Update  allowed 
J  Update  if  null  allowed 
K  Mandatory 
L  Fixed  length 
K  Auto  3)cip 
N  No  echo 
0  Auto  help 
P  Uppercase 
Q  List  of  values  exist 
R  Low  value  exist 
S  High  value  exist 
T  Help  message  exist 


Key  Triggers 

Other  Triggers 

a  ClrBDt 

k 

Post-Change 

b  ClcFra 

B 

Pre-Field 

c  ClrRec 

C 

Post-Field 

d  Comait 

D 

Pre-Query 

e  CQuery 

E 

Post-Quewry 

f  CceRec 

r 

Pre-Insect 

g  DelRec 

G 

Post-Insret 

h  DupFid 

H 

Pre-Update 

i  DupRtc 

I 

Post-Update 

j  EntQry 

J 

Pce-Delete 

)c  ExsQcy 

K 

Post-Delete 

1  Exit 

L 

Pre-Record 

m  LlstVal 

M 

Post-Record 

n  Menu 

N 

Pre-Bloc)c 

o  NxtBlIc 

0 

Post-Block 

p  HxtFld 

P 

Pre-Fora 

q  NxtKey 

Q 

Post-Fora 

r  NxtRec 

s  NxtSat 

t  PrvBDt 

u  PrvFld 

V  PrvReo 

w  others 
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Fens  Tectnical  CesczlfCim  (paitial  onpiiauai) 
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Len 

Field  Attnhures 
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Vey  triggers 
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Conclusions 


Methodology 


User  Group  Profil 


Required  Tools 


Participant's  Objectives 


Methodology  as  implemented  in  ECCO 


Participant's 

Acceptance 


Onc0  defined,  the  methodology  is  presented  and 
explained  to  each  paniopaht: 


Projea  Sponsor 

Users 

Oevelooers 

Parallel  Projects 


User  Group  *  proiea  sponsor  appoims  a  core  user  group  which  has  as  a 

speafic  task  the  responsibility  of  actively  participating  in  the 
development  of  the  system. 


Technoiogy 


The  implememation  of  the  prototyping  process  requires  the  rapid 
installation  of  proven  technologies  and  tools  such  as  screen 
and  coda  generation.  This  allows  the  deveiopeis  to  spend  more 
lime  with  the  users,  refining  requirement  needs  rather  than  struggling 
with  difficult  and  tedious  programming  in  the  earty  phases  of  the  proiect. 


CQi 


User  Group  Profile 


Location  *  Canadian  Forces  Bass  Valcamer.  Quebec.  CANADA 

Sth  Engineer  Peg.  of  Canada.  This  is  the  largest  engineenng 
bass  in  Canada,  the  2nd  largest  in  the  Canadian  Land  Forces 

•  Close  oroximity  to  the  development  team  at  D.R.E.V. 


Active 

Participants 


■  Active  oarticioams  rank  from  Major  (proisa  soonsor), 
Captain  (engineer  commander),  sargeants  and  corporals 

•  Pahiapants  were  chosen  because  they  represent  the 
typical  profile  of  end  users  and  have  vast  experience  in 
engineer  tactical  operations. 


External 

Participants 


A  multi'level  user  group  is  essential  to  the  success 
of  the  project,  ft  therefore  also  includes  higher  ranking 
command  officers  to  ensure  that  all  venical  engineenng 
requirements  are  met. 
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Required  Tools 


E  -  R  Diagram  Data  Modeling 


Functionai  Decomposition  Diagramming 


Interactive  Program  Prototyping  (4GL  based 


Report  Prototyping 


Documentation  Generation 


Data  and  Component  Dictionary 


Participant's  Objectives 


Project 

Manager 


•  Usar's  Sallsfaetlon 

•  Productivity 

•  OallvarabiM 

•  Rtducod  Costs 

•  RMlIstIc  Work  Schodulo 

•  Moot  Hoquiromonts 

•  Technology 


Deveioper 


>  More  accurate  analysis  work 

•  Functioning  and  Valid  Sottware 

•  Technological  Challenge 

•  Recognition 

•  Improved  professional  end  managerial  skills 


U30y  •  Get  a  complete  end  correct  system  the  first  time 

•  Enhanced  Implication  In  development 

•  Rapid  contact  with  technology 

•  Rapid  access  to  deliverables 

•  Concrete  results 

•  Responsibility  and  ownership  of  system 
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Technical  Presentation  13 


"Requirements  Engineering  Testbed" 


Mr.  William  E.  Rzepka 
Rome  Air  Development  Center,  USA 


WIAT  ARE  R£0UIR£^€NTS7 


REOUIREftNIS  ARE  PRECISE  STATE(€NTS  OF  NEED  INTENOffl 
TO  CONVEY  UNDERSTANDING  AUOUT  A  DESIRED  RESULT 


EXTERNM.  aiARACTEltlSTICS 
CONSTRAINTS 

PERFORWNCE 

RELIABILITY 

SAFETY 

COST 

IDDEL  OF  MAT  IS  NEEDED 
STATEtfMT  OF  PfiOELEH  TO  BE  SOLVED 


IT  PAYS  TO  CATCH  ERRORS  EARLY 


PHASE  IN  NHICH  tAROR  IS  OCtECtCD 
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CORE 

CONTROILED  RECXJIREMEhfTS  EXPRESSION 


VIEWPOINT  1 


HESSIuSSHi 

■H 

9H 

ISffiKijlJWOTjTJ 

HB 

Ullfl 

B 

■ 

lESnSiSSi 

HHHHI 

■ 

■ 

IHEIusSSIH 

H 

EagKyigiMiiTjg 

■■Hill 

■ 

■ 

H 

COMBMEO  VIEWPOINT  ANALYSIS 

I 


SYS?EM 

CONSTRAINTS 


RAPID  PROTOTYPING  SYSTEM 


RPS 


USER  INTERFACE 
PROTOTYPING 

_ t _ 

PERFORMANCE 

MODELING 

DATA 

MODEUNG 

•COLOR 

•  WORLD  DATA  BANK  I 

•  GRAPHICS/MENU  INPUT 
•ACTIVE  REGIONS 

AUDIBLEA/ISUAL  AURMS 
DATA  BASE  ACCESS 
SCENARIOS 
■DYNAMIC  GRAPHICS 


COMPUTER 
H/W  &  S/W 


COMMUNICATIONS 

NETWORK 


ANALYST 

WORKFLOW 


SYSTEM  FUNCTION 
ALLOCATION 

•  MENU/TEMPLATE  INPUT 
•QUERY  OUTPUT 


•RELATIONAL  MODEL 
•  QUERY  &  UPDATE 
•PERFORMANCE 
ESTIMATION 
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CORE 

CONTRXLED  R83UIHEMENTS  EXPRESSION 


flATASTOJgWBF 

ANALYSIS 


ilATAST^UfiTORE' 

ANALYSIS 


SINOli 
VIEWPOWT 
ANALYSIS  ■ 


VIEWPOIMr 

analysis  ■ 


■1 

mui 

a 

COMBMED  VCWPOINr  ANALYSIS 


CONSirRAWTS 


RAPID  PROTOTYPING  SYSTEM 


RPS 


USER  INTERFACE 
PROTOTYPING 

1 

_ X. _ 

PERFORMANCE 

MOOEUNG 

- ■> 

DATA 

MODELING 

•  COLOR  I 

•WORLD  DATA  BANK  I 
•(jP.APHICSrtAENU  INPUT 

•  ACTIVE  REGIONS 

AUDIBLE/VISUAL  ALARMS 
DATA  BASE  ACCESS 
SCENARIOS 

•  DYNAMIC  GRAPHICS 


COMPUTER 

H/W&S/W 


I  COMMUNICATIONS 
NETWORK 


ANALYST 

WORKaOW 


•  RELATIONAL  MODEL 

•  QUERY  &  UPDATE 

•  PERFORMANCE 
ESTIMATION 


SYSTEM  FUNCTION 
ALLOCATION 

•  MENUHEMPLATE  INPUT 

•  QUERY  OUTPUT 
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PROTO 


OBJECTIVE 

RAPIDLY  SPECIFY  A  PROGRAM  THAT  EXECUTES  SPECIRC 
TARGET  SYSTEM  FUNCTIONS 

APPROACH 

VERY  HIGH  LEVEL  GRAPHICAL  LANGUAGE  FOR 
INTERCONNECTING  SOFTWARE  MODULES 

ENVIRONMENT  SUPPORTING- 
STEPWISE  REFINEMENT 
CONVENTIONAL  PROGRAMMING 
REUSE  OF  APPUCATTON-SPECIHC  MODULES 
EXECUTABLE 


RET STATUS 


CORBANALYST  •  SEAI70BJVERY 
VHU  TOOLS  •  OCTU OfUVERY 
RP3  -FEBM  OEUVCRY 
RE  WORKSTATUN INTEORATION  •  MI042 

APPUCATTONS 
COREANM.YSSaFRP8 
OFD  ANALYStSOFRPS 
RPSUBBt  NTSVACS  PROTOTYFES 
AIROeFENSSSCeURO 
.  AIR  OCFBOE  OPERATIONS  CENTER  nSPLAYS 
ADVANCED  COMMANO  AM  CONTROL  EmRa«a>n^ 
EVALUATION 

ANALYST  USSt  COMMENTS  NCORPORATEDMVERSnNU 
RPSOOAMBnStCORPORATEONPORANDCOR 
AIR  OEFBOE  SCENARIO  PROOOCnvmr.  XJS 
AOOC  DISPLAYS  PHOOyCnVrTY-  x« 
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Requirements  Engineering  Testbed 


INDIVIDUAL  TOOL  INTERFACE  STYLES 


CORENTERFACE  PROTO  INTERFACE  RPS  INTERFACE 


CORE 

LOGICAL 

DATA 


D-142 


1992  REQUIREMENTS  ENGINEERING  TESTBED 


REED  ENHANCEMENTS  TO  THE  RPS 


USER  INTERFACE  MODELING 

•  INTEGRATE  INDIVIDUAL  TOOLS  INTO  SINGLE  INTERFACE 

•  PROVIDE  INTEGRATED  DYNAMIC  CAPABILITY 

PERFORMANCE  MODELING 


•  PROVIDE  GRAPHIC  INTERFACE  TO  MODELS 


This  page  is  intentionally  left  blank. 
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